[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [LTP] ulimit01 on test7



The project page says LTP is "for testing and stressing the Linux Kernel 
and related features" so I don't think we need to remove it just because
it's a libc test.  

But if the call is obsolete and no one is going to fix it and no one 
cares if it's broken, then I don't see any reason to test it.  But,
as you say, there might be codes using it so we don't know that no one
cares.  In this case, I'd rather err on the side of providing more
information and letting the community decide whether or not they care
about the failure.  

The DejaGnu testing Framework (http://www.gnu.org/manual/dejagnu/index.html)
had an XFAIL status that I think was for this type of thing.  If I 
understood correctly you could use XFAIL for test cases showing old
failures, as in, yes this is a problem but we already know about it
and maybe someday someone will fix it.

This is a good issue to discuss because we need to distinguish between
new failures (you just broke this!) and known problems (it's already
on the list to fix and not related to your mods).

janet

-- 
________________________________________________________________________
Janet Clegg                                         janet.clegg@sgi.com
Silicon Graphics, Inc                               651) 683-5207

Aaron Laffin wrote:
> 
> I noticed at ulimit01 fails on 2.4.0-test7 as follows:
> 
> $ ./ulimit01
> ulimit01    1  PASS  :  ulimit(1, -1) returned 4194303
> ulimit01    2  FAIL  :  ulimit(2, -1) returned 0
> ulimit01    3  PASS  :  ulimit(2, 4194303) returned 0
> ulimit01    4  PASS  :  ulimit(2, 4194302) returned 0
> $ uname -a
> Linux barn 2.4.0-test7 #2 Thu Aug 24 09:12:50 PDT 2000 i586 unknown
> 
> This passes on 2.2.x.  However, there are a couple issues: 1) this is
> not necessarily a kernel test.  ulimit() is a libc test.  2) the man
> page is clear in stating that ulimit() is obsolete.  So, should we be
> alarmed that it is failing -- there might be codes out there that use
> it.  Should we remove this test?  Thoughts?
> 
> --aaron
> 
> --
> Aaron Laffin
> Silicon Graphics, Inc. OS Test Development
> Email: alaffin@sgi.com Voice: 651-683-5756
> USA/MN/CRP/F5233/SSBU