Hi! > > I don't see any way to find out range from user-space. > > Even with CONFIG_SCHED_DEBUG, sched_domain->level isn't exported to /proc. > > > > I think whole test isn't much useful, as it is very unlikely > > you would have all scheduling domains available: > > http://lxr.linux.no/#linux+v2.6.38/kernel/sched.c#L6995 > > > > Quoting Peter Zijlstra: > > "More like, use sched_debug boot parameter and see your dmesg output. > > I've recently merged a patch that makes the whole level thing completely > > dynamic, there's no more fixed levels." > > > > At the moment, I'm out of ideas how to find out acceptable range. > > 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. -- 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
