Hi,
> On Thu, 2008-09-11 at 21:47 +0900, Masatake YAMATO wrote:
> > > Finally i tested them and were satisfied with the way it built,
> > > installed and ran on 4 arch i tested. But, i am puzzled by one thing. On
> > > all systems (even on kernel 2.6.26 for i386, ppc64, x86_64) it gave me
> > > the following output:
> > >
> > > # ./testcases/bin/signalfd01
> > > signalfd01 1 CONF : System doesn't support execution of the test
> > > # echo $?
> > > 0
> > >
> > > While i found that signalfd.h is existent here:
> > > /usr/include/linux/signalfd.h
> > > (in one of the machines)
> > >
> > > Should we actually find for:
> > > /usr/include/sys/signalfd.h ?
> > >
> > > instead of:
> > > /usr/include/linux/signalfd.h
> > >
> > > Should we actually wait for a higher gcc release for this header file. I
> > > have even the following gcc in one of my test machine:
> > >
> > > # gcc --version
> > > gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> > >
> > > Anyways, the tests are now part of LTP. I hope i will be able to run the
> > > actual test code soon on some machine. Thanks.
> >
> > In such situation what we should do?
> > I'd like to hear about the basic policy from you?
>
> Hmmm...!! That puts me in a difficult position. So far u personally
> think, i would like things to get tested if the running kernel has the
> support for it, even, if the installed glibc does not have support for
> this. We would then be able to test features in latest kernels even if
> glibc is far away to include it´s support. It will mean putting some
> glibc type code in the test case(s). Not sure what others think on this.
>
> Regards--
> Subrata
I see.
Here is a general rule for writing test cases for newer system calls.
If you find something wrong please modify.
(1) If glibc provides interface, we SHOULD write a test case on it.
We can test kernel code through glibc.
(2) If we have more time, we will add a test case on header files
provided by kernel. So we can test the system call even if
glibc has not provided a header file for it yet.
(3) If no header file neither sys/foo.h and linux/foo.h, We SHOULD
add a fallback to report it like:
testcases/kernel/syscalls/inotify/inotify01.c
int
main()
{
#ifndef __NR_inotify_init
tst_resm(TWARN, "This test needs a kernel that has inotify syscall.");
tst_resm(TWARN, "Inotify syscall can be found at kernel 2.6.13 or
higher.");
#endif
#ifndef HAS_SYS_INOTIFY:
tst_resm(TBROK, "can't find header sys/inotify.h");
return 1;
#endif
return 0;
}
#endif
In the report, the test case should tell from which version the system
call may be available.
I'm not sure I should check __NR_inotify_init and HAS_SYS_INOTIFY.
But for a while I'd like to ignore these details.
One thing we have to decide now is which test status I should use when
the header files is not found. inotify01.c uses TBROK. signalfd uses
TCONF like:
int
main(int argc, char** argv)
{
tst_resm(TCONF,
"System doesn't support execution of the test");
return 0;
}
Masatake
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
