On Thu, Sep 11, 2008 at 9:24 AM, Subrata Modak
<[EMAIL PROTECTED]> wrote:
> 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
>
>> How strongly should we seek the portability of test case?
>>
>> See the patch attached to this mail.
>> If I copy codes from glibc, even on your systems the test case
>> for signalfd can be run. Do you want this kind of effort?
>>
>>
>>
>> Signed-off-by: Masatake YAMATO <[EMAIL PROTECTED]>
>>
>> diff --git a/testcases/kernel/syscalls/signalfd/Makefile
>> b/testcases/kernel/syscalls/signalfd/Makefile
>> index be34bb1..db37fd4 100644
>> --- a/testcases/kernel/syscalls/signalfd/Makefile
>> +++ b/testcases/kernel/syscalls/signalfd/Makefile
>> @@ -20,7 +20,9 @@ include ../utils/cond.mk
>>
>>
>> CFLAGS += -I../../../../include \
>> - $(call check_header,sys/signalfd.h, -DHAS_SIGNALFD_H, ) -Wall
>> + $(call check_header,sys/signalfd.h, -DHAS_SYS_SIGNALFD_H
>> -DHAS_SIGNALFD, ) \
>> + $(call check_header,linux/signalfd.h, -DHAS_LINUX_SIGNALFD_H
>> -DHAS_SIGNALFD, ) \
>> + -Wall
>> LDLIBS += -L../../../../lib -lltp
>>
>> SRCS = $(wildcard *.c)
>> diff --git a/testcases/kernel/syscalls/signalfd/signalfd01.c
>> b/testcases/kernel/syscalls/signalfd/signalfd01.c
>> index da3b258..e9a3b60 100644
>> --- a/testcases/kernel/syscalls/signalfd/signalfd01.c
>> +++ b/testcases/kernel/syscalls/signalfd/signalfd01.c
>> @@ -50,9 +50,31 @@ TCID_DEFINE(signalfd01);
>> int TST_TOTAL = 1;
>> extern int Tst_count;
>>
>> -# ifdef HAS_SIGNALFD_H
>> +# ifdef HAS_SIGNALFD
>> +
>> +#ifdef HAS_SYS_SIGNALFD_H
>> +
>> #include <sys/signalfd.h>
>>
>> +#elif HAS_LINUX_SIGNALFD_H
>> +
>> +#include <linux/types.h>
>> +#include <linux/signalfd.h>
>> +#include "linux_syscall_numbers.h"
>> +
>> +#ifndef __NR_signalfd
>> +#define __NR_signalfd 0
>> +#endif
>> +
>> +int
>> +signalfd(int fd, const sigset_t *mask, int flags)
>> +{
>> + /* Taken from GLIBC. */
>> + return (syscall(__NR_signalfd, fd, mask, _NSIG / 8));
>> +}
>> +
>> +#endif
>> +
>> void cleanup(void);
>> void setup(void);
>>
>> @@ -315,7 +337,7 @@ cleanup(void)
>> }
>>
>>
>> -#else /* !HAS_SIGNALFD_H */
>> +#else /* !HAS_SIGNALFD */
>>
>> int
>> main(int argc, char** argv)
>> @@ -326,4 +348,4 @@ main(int argc, char** argv)
>> }
>>
>>
>> -#endif /* !HAS_SIGNALFD_H */
>> +#endif /* !HAS_SIGNALFD */
Why not default with whatever's the newest standard, then fallback to
the deprecated version?
FWIW, not all systems have signalfd.h at:
/usr/include/linux/
not should you look for that header there if cross-compilation is
being performed.
The implementer should pass that in the CROSS_CFLAGS, like so make
CROSS_CFLAGS="-I/usr/include/linux"
Some food for thought.
Cheers,
-Garrett
-------------------------------------------------------------------------
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
