Thanks.
On Tue, 2008-09-16 at 22:37 +0900, Masatake YAMATO wrote:
> 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.
>
I will make this available to the WIKI as well.
Regards--
Subrata
> (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
