On Wed, May 7, 2008 at 5:22 AM, Subrata Modak <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-05-07 at 12:12 +0100, Will Newton wrote:
> > On Tue, May 6, 2008 at 4:12 PM, Subrata Modak
> > <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > I was going through Will Newton´s Patch on the sysfs syscalls he
> > > recently submitted to LTP:
> > >
> > >
> http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/kernel/syscalls/sysfs/,
> > >
> > > and was thinking whether we can use this approach to Patch all the
> > > existing syscall test cases in LTP for avoiding build failure on
> > > machines, where this is not supported. May be it will reduce the task
> of
> > > checking Kernel Version Support, Architecture Support, Glibc Support
> and
> > > all that we do in our test cases to avoid build failure.
> > >
> > > Mike/Will,
> > >
> > > Do you think this can be a better approach ?
> >
> > There are a number of reasons why a syscall may not be supported on an
> > architecture:
> >
> > 1. It's a uClinux architecture and so drops support for a few things
> > like fork(2) and mmap(2). It appears from looking at the Makefiles
> > that the uClinux architectures are fairly well supported by LTP now,
> > although I don't have one available to test that.
> >
> > 2. The syscall is obsolete so not implemented by a modern Linux
> > architecture. It is the C library's job to smooth away these
> > differences IMO. For example I don't think it is useful for LTP to be
> > checking explicitly that old system calls for e.g. 16bit uids versus
> > 32bit uids work, just that get getuid(2) works.
> >
> > 3. sysfs is a particularly strange case because whilst it has been
> > around a long time the C library provides no wrapper for it so it must
> > be called as a raw syscall in the style of "syscall(NR_...)". If a
> > test needs to use a raw syscall like this IMO these type of tests
> > should use #ifdef NR_,
> >
> > 4. The syscall is new and not yet supported by an architecture. This
> > is the tricky one - if the syscall number is present there is no
> > guarantee of C library support and one has to revert to raw syscalls
> > and other nasty hacks to get it working until the C library support is
> > widespread. I think if possible it should be ensured that any new
> > tests try not to break older architectures and use an #ifdef when
> > doing this.
> >
> > >From my point of view as someone who uses LTP on a non-mainstream
> > architecture I think it would be simpler to blacklist rather than
> > whitelist testcases - we can start with an empty blacklist and just
> > disable one at a time and investigate each failure. However I'm not
> > sure how a test is best disabled, is it best to print a warning to
> > remind you that this syscall is not being tested on this architecture
>
> Yes, the best is to compile the test, but WARN during run. With that we
> can keep track of what test cases are supported and which are not. If
> you simply disable compilation, then we loose that track.
>
> --Subrata
>
> > (and perhaps should be) or to just not build that test in the first
> > place? I think probably best to warn, but you may disagree.
> >
> > I think I would prefer a configure-like approach to enable/disable
> > larger sections of the testsuite for things like NPTL or RT. It has a
> > number of advantages from my point of view:
> >
> > We're using uClibc which sometimes does not have all the latest and
> > greatest system calls and functionality. It can also be configured to
> > not support areas of functionality for size reasons and has few
> > formally released version so it's hard to say quite what a uClibc
> > system supports. The kernel is the same - it is possible to turn off
> > e.g. SysV IPC - so you may just want to not build those tests.
> >
> > On an embedded or small system you may not want to support NPTL or the
> > new RT functionality even if it is possible that your kernel can. It
> > is also helpful to be able to disable tests if you know your system
> > will not use e.g. pthreads and you only want to verify that the rest
> > of the system calls work to save time.
>
>
Speaking on the note of NPTL, some of the machines at Cisco are running an
antiquated version of the Linux kernel (2.6.9~something) and lack NPTL
support in the libc that came stock on the machines, so they fail at the
very same spot I assume.
I'm not saying let's go for autoconf / automake, but maybe stuff should be a
bit intelligent in terms of ensuring that feature X exists in the
environment before building.
-Garrett
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
