Hi!
> >>     Just make the test only run on kernels without that particular
> >> functionality. I assume that's possible in some way, or was the author
> >> not nice enough to do that (I have to remember that this is Linux and
> >> sane versioning with kernel/userland sources, etc aren't commonplace
> >> like BSD)?
> >
> > It's more complicated than that. There are several kernel constants that
> > are considered internal, these may be changed by config knobs
> > architecture or particular commit. And sometimes there is no way to get
> > these from running kernel (as it doesn't make sence to get them until
> > you are trying to test that particular part of the kernel works some
> > way).
> >
> > Even more the kernel is every changing codebase, so what was influenced
> > by constant may not exist anymore (and the interface for userspace
> > don't need to be changed at all) just internal implementation.
> >
> > And if that's the case. I would rather get rid of test that rely on some
> > kernel internals and speculated behaviour, rather than spending eternity
> > patching it for each release.
> 
>     Fair enough. It would be nice if there was some way to expose this
> information via debug /proc (or better -- /sys) entries though.
> Otherwise doing graybox / whitebox testing of the Linux kernel is
> impossible.
> Thanks,

Well yes, the problem here is that linux kernel wasn't really made to be
testeded (and that is true even for POSIX at least partially) we need
probably to do some talks to let the kernel people know that if they
want good testsuites, they need to lend a helping hand.

-- 
Cyril Hrubis
[email protected]

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to