Am 29.03.2015 um 17:06 schrieb Hajime Tazaki: >> 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. Yep, tool/libos is also perfectly fine. >> 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. The questions is, why do you need stubs which are a no-op but not a lib_assert(false). Sounds more like these dependencies shouldn't be linked at all. Same applies to lib_assert(false) stubs. If they must not get called from libos better try hard to avoid these dependencies at all. > 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. As noted before, libos is something in between. Maybe the asm-generic stuff needs some modifications to make it work for libos. > 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. BTW: There is something really fishy wrt to your build process. I did a ARCH=i386 build due to my regular kernel work and later a ARCH=lib build. It seems to pickup old/unrelated object files. After a make clean ARCH=i386 it build fine. ---cut--- LIB liblinux-4.0.0-rc5.so /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: Warning: size of symbol `skb_copy_bits' changed from 10 in ./kernel/bpf/core.o to 441 in ./net/core/skbuff.o ./net/ipv6/fib6_rules.o: In function `fib6_rule_lookup': /home/rw/linux/net/ipv6/fib6_rules.c:34: multiple definition of `fib6_rule_lookup' ./net/ipv6/ip6_fib.o:ip6_fib.c:(.text+0xd50): first defined here /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/sysctl.o' is incompatible with i386:x86-64 output /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/params.o' is incompatible with i386:x86-64 output /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/notifier.o' is incompatible with i386:x86-64 output /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/time/time.o' is incompatible with i386:x86-64 output /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/rcu/update.o' is incompatible with i386:x86-64 output /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/locking/mutex.o' is incompatible with i386:x86-64 output /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/locking/semaphore.o' is incompatible with i386:x86-64 output /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/locking/rwsem.o' is incompatible with i386:x86-64 output /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: i386 architecture of input file `./kernel/bpf/core.o' is incompatible with i386:x86-64 output [...] ./kernel/rcu/update.o:(.ref.data+0x20): undefined reference to `trace_event_raw_init' collect2: error: ld returned 1 exit status arch/lib/Makefile:223: recipe for target 'liblinux-4.0.0-rc5.so' failed make: *** [liblinux-4.0.0-rc5.so] Error 1 ---cut--- While we're talking about the build process, how can I cross build libos? Say a i386 libos on x86_64. For UML we have use SUBARCH. i.e. make linux ARCH=um SUBARCH=i386 Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html