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 (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. ------------------------------------------------------------------------- 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
