On Thu, Nov 25, 2010 at 10:44 AM, Cyril Hrubis <[email protected]> wrote:
> Hi!
>> >>>>>> ...
>> >>>>>>>> int main()
>> >>>>>>>> {
>> >>>>>>>> @@ -133,6 +152,12 @@
>> >>>>>>>>
>> >>>>>>>> struct sigaction sa;
>> >>>>>>>>
>> >>>>>>>> + /* Checking for Kernel Version */
>> >>>>>>>> + if ( kernel_ver_cmp(2, 6, 21) != 0 )
>> >>>>>>>> + {
>> >>>>>>>> + UNTESTED( "sem_wait() returned EINTR on kernel
>> >>>>>>>> versions
>> >>>>>>>> lower than 2.6.22" );
>> >>>>>>>> + }
>> >>>>>>>> +
>> >>>>>>>> /* Initialize output */
>> >>>>>>>> output_init();
>> >>>>>>>>
>> >>>>>>>> ============
>> >>>>>>>>
>> >>>>>>>> Above patch is revision only for templates.
>> >>>>>>>> The following procedure is necessary after applying patch:
>> >>>>>>>> ------------
>> >>>>>>>> #cd testcases/open_posix_testsuite/conformance/interfaces/sigaction/
>> >>>>>>>> #./gentests.pl
>> >>>>>>>> ------------
>> >>>>>>>>
>> >>>>>>>> Similar revisions are necessary for other 25 "sigaction" tests.
>> >>>>>>> Sorry, but Linux-isms can't leak into the open_posix_testsuite.
>> >>>>>>> Same with BSDisms (at least they shouldn't... if they do, then slap
>> >>>>>>> me
>> >>>>>>> or whoever did the commit).
>> >>>>>> Do you mean the culprit is Linux-isms?
>> >>>>> Mitani-san is proposing that I `fix' the testcases to work on RHEL
>> >>>>> 4.8. These testcases should function with minimal change for all
>> >>>>> versions of Unix.
>> >>>>>
>> >>>> This open_posix_suite is the part of LTP(linux test project), must we
>> >>>> make sure it can work at all versions of unix?
>> >>> I use it in FreeBSD and others have used it in other versions of Unix
>> >>> (in the past), based on the README. There's no reason why we need to
>> >>> maintain something that philosophically diverges from the upstream
>> >>> project's goal because it will make merging more painful and
>> >>> unnecessary.
>> >>>
>> >> OK, i get it. Thanks. ^_^
>> >>
>> >> Then, whether should we remove the following case, because it invokes
>> >> the uname that it's not exsit at 4.3 BSD.
>> >> conformance/interfaces/pthread_mutex_init/speculative/5-2.c
>> >>
>> >
>> > The uname() is part of the POSIX, for sure it's available on BSD.
>> >
>>
>> Maybe i miss somethings, but the IEEE Std 1003.1-2008 said:
>> "The uname() function originated in System III, System V, and related
>> implementations,
>> and it does not exist in Version 7 or 4.3 BSD. The values it returns are
>> set at system
>> compile time in those historical implementations."
>
> Well BSD 4.3 has been released in 1986. The recent BSD systems (tested
> on FreeBSD 8.0) should be fine.
The uname system call is fairly standard on all versions of Unix
(and guess what folks -- it's POSIX standard too!).
The point wasn't to discount the value of adding uname, but where
do you stop in trying to ?
If you guys want functionality to _remove_ testcases for local
execution, then I'm willing to help there. Otherwise, there will be no
end to this hack mess.
>> > Thinking of it, the patch that checks for kernel version only when
>> > sysname == Linux should compile and work. But the question here is if we
>> > want to bloat the tests with workarounds for broken systems. I would
>> > rather see this covered by a database of known issues, so you can easily
>> > copare results and read why your system is broken.
>> >
>>
>> OK, if we have this database, it looks good to me.
>>
>
> Garrett pointed out the results mailing list. I'm however not reading
> it either.
Yes, because it's mostly spam and a support email alias nowadays
(instead of the emails coming here they go there >:(...). I need to
come up with a script anyhow to aggregate the results and ship them
off via LTP (not the open_posix_testsuite because I'm not going to
commit those bits there). IIRC there's a script in tools that can do
that.
Thanks,
-Garrett
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
