lkml.org 
[lkml]   [2015]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)
    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


    \
     
     \ /
      Last update: 2015-03-30 09:21    [W:4.425 / U:1.216 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site