Hi Richard, At Fri, 27 Mar 2015 10:21:59 +0100, Richard Weinberger wrote: > Just an idea popping out of my head... > > What about putting libos into tools/testing/ and make it much more generic and framework alike. it's trivial though, libos is not only for the testing (i.e., NUSE). # of course tools/libos or something can be the place. > With more generic I mean that libos could be a stubbing framework for the kernel. > i.e. you specify the subsystem you want to test/stub and the framework helps you doing so. > A lot of the stubs you're placing in arch/lib could be auto-generated as the > vast majority of all kernel methods you stub are no-ops which call only lib_assert(false). the issue here is the decision between 'no-ops' and 'assert(false)' depends on the context. an auto-generated mechanism needs some hand-written parameters I think. one more concern on the out-of-arch-tree design is that how to handle our asm-generic-based header files (arch/lib/include/asm). we have been heavily used 'generic-y' in the Kbuild file to reuse header files. OTOH, I agree with you on the point of auto-generated glues (stubs), or trying to avoid glues (reuse the originals as much as possible) as Antti mentioned. that will definitely be reduce the amount of maintenance effort. -- Hajime -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>