On Mon, Mar 23, 2009 at 6:31 AM, Serge E. Hallyn <se...@us.ibm.com> wrote:
> Quoting Garrett Cooper (yaneg...@gmail.com):
>> On Mar 20, 2009, at 9:19, "Serge E. Hallyn" <se...@us.ibm.com> wrote:
>>
>>> (Against the March intermediate release)
>>>
>>> mqns support is expect in 2.6.30, not 2.6.29.
>>>
>>> Signed-off-by: Serge Hallyn <se...@us.ibm.com>
>>> ---
>>> .../kernel/containers/mqns/check_mqns_enabled.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/testcases/kernel/containers/mqns/check_mqns_enabled.c b/
>>> testcases/kernel/containers/mqns/check_mqns_enabled.c
>>> index a369921..169e8c9 100644
>>> --- a/testcases/kernel/containers/mqns/check_mqns_enabled.c
>>> +++ b/testcases/kernel/containers/mqns/check_mqns_enabled.c
>>> @@ -34,7 +34,7 @@ int main()
>>> int pid;
>>> mqd_t mqd;
>>>
>>> - if (tst_kvercmp(2,6,29) < 0) /* only in -mm so far actually
>>> */
>>> + if (tst_kvercmp(2,6,30) < 0) /* only in -mm so far actually
>>> */
>>> return 1;
>>>
>>> mq_unlink("/checkmqnsenabled");
>>> --
>>> 1.5.6.3
>>
>> Sorry if I contradict what I said earlier, but what if someone
>> backported this patch to an earlier kernel version? What if someone
>
> Then they can make the trivial change back (as I do to test with
> -mm).
>
>> didn't enable this support in their kernel with one of the supported
>> versions?
>
> checkmqnsenabled goes on to check for posix mq support and for
> IPC namespaces support. If both of those are present, then the
> support is there. If either is missing, then it is not.
>
> The reason we need the version check is that on an older kernel,
> posix mq support and IPC namespaces support can both be enabled
> but the support (of course) for posix mq namespaces is not there.
Ah, thanks for the explanation.
>> Is there a better way to check for this support and other
>> version specific features (autoconf?)?
>
> No, autoconf has nothing to do with it. The problem is that there's
> really no way to check for the feature other than testing the
> feature itself, which the testcases of course are doing. The goal
> of this is just to not annoy users with spurious FAILs.
Well... what I meant is that autoconf can test to see whether or not
the machine is affected by running a quick test program, but this
can't be solved with cross-compilation environments. It'd be another
switch to add to the many potential switches to be fed into
configure...
>> I'm starting to see what Mike F.
>> was trying to bring up about the futility of version checking like
>> this...
>
> Well we can just always run the tests, but ltp will lose a lot
> of users (including me). Or, we can never automatically run the
> tests and require they all be run by hand. That'd be fine with
> me. There are some testcases like hackbench and growfiles and
> some memtests that I'd rather not run automatically when I'm
> just testing for functionality regressions and not stresstests.
>
> But IMO the way it is now is a touch fragile (by necessity), but
> ok. You simply can't programatically detect the difference
> between an older kernel which doesn't support posix mq namespaces,
> and a newer kernel where they are broken.
Would it be acceptable to instead insert a WARN message beforehand and
reference the caveat behind using mq in a previous kernel version,
like was done with inotify02 recently, so that way the test is run,
but the user is educated on the fact that the results could be a bit
misleading?
Thanks,
-Garrett
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
