LWN: Comments on "Running the kernel in library mode"

Running the kernel in library mode

thehajime — Thu, 16 Apr 2015 03:06:09 +0000

as mathieu_lacage mentioned, it's not that bad to maintain the kernel internal changes.

> In practice, it appears that a couple hours of work once 2 to 3 months is enough to maintain this code.

Running the kernel in library mode

viro — Thu, 16 Apr 2015 02:10:54 +0000

... and get screwed as soon as kernel internals change. What, does anybody expect that we'll accept the stability obligations on anything other than syscalls? If anyone tries to argue that *and* arch/libos maintainers don't tell the to piss off convincingly enough, well, git rm arch/libos will solve the entire problem just fine, TYVM...

Running the kernel in library mode

thehajime — Thu, 16 Apr 2015 01:57:13 +0000

we elaborate this idea to other system calls, like socket(2) for instance at the moment.

Running the kernel in library mode

scientes — Thu, 16 Apr 2015 00:41:01 +0000

and time() already works that way.

Running the kernel in library mode

thehajime — Sun, 12 Apr 2015 02:55:32 +0000

exactly. your application theoretically can call functions without system calls.

Running the kernel in library mode

robbe — Sat, 11 Apr 2015 20:52:57 +0000

I guess this is only useful for applications that are GPL-2 compatible? NS-3 is GPL-2. NUSE, true to github form, has no license...

Running the kernel in library mode

gdt — Sat, 11 Apr 2015 12:56:52 +0000

Does this means that internal Linux functions now become part if the user-visible API (via LibOS rather than via system call), and thus have to be stable?

Running the kernel in library mode

tom.prince — Fri, 10 Apr 2015 16:00:15 +0000

It seems like this is something that would be useful for writing a test-suite for the kernel.

Running the kernel in library mode

justincormack — Thu, 09 Apr 2015 17:01:56 +0000

Yes that should be possible. Working on doing this kind of thing with the NetBSD rump kernel, which is a similar architecture.

Running the kernel in library mode

justincormack — Thu, 09 Apr 2015 16:57:53 +0000

Indeed, there has been quite a lot of contact. The rump kernel has sorted out how to keep the rump kernel synced - it is used heavily in the test suite, for example, so it is clear when it is not working.

The next step

epa — Thu, 09 Apr 2015 14:45:36 +0000

That's an x86 emulator - which obviously has been possible for ages. It is not compiling Linux directly to Javascript.

The next step

pr1268 — Thu, 09 Apr 2015 12:43:54 +0000

Didn't Fabrice Bellard already do that?

The next step

epa — Thu, 09 Apr 2015 11:40:34 +0000

Now we need only compile LibOS to Javascript to run it in the browser, and Linux development will be complete.

Running the kernel in library mode

SLi — Thu, 09 Apr 2015 10:54:07 +0000

I wonder if the result is sufficiently normal user space code that one could, for example run it (or the binary it's linked to) under Valgrind, or to compile it with some kind of instrumentation (for example, AddressSanitizer or some kind of branch instrumentation for profile guided fuzzing)?

Running the kernel in library mode

dunlapg — Thu, 09 Apr 2015 09:32:43 +0000

Sounds a lot like the "rump kernel" work that the NetBSD guys have been doing:

http://rumpkernel.org/

Running the kernel in library mode

mathieu_lacage — Thu, 09 Apr 2015 06:43:42 +0000

Dear editor,

1) the ns-3 DCE component that can be used to instantiate multiple libos instances within a single process does not use LD_PRELOAD tricks. Instead, it relies on either the dlmopen function (implemented with an adhoc ELF Loader that is binary compatible with the glibc loader) or a piece of code that plays tricks with the ELF binaries.

2) I have seen this statement a lot of times: "LibOS will be broken much of the time" and I have been unable to dispel that myth yet. In practice, my experience has been that it is not the case and it seems to boil down to the fact that the internal interfaces that are plugged in appear to be much more stable than feared by most kernel developers (I shared that fear at some point a couple of years ago). Or maybe I have a different appreciation for what "most of the time" means. In practice, it appears that a couple hours of work once 2 to 3 months is enough to maintain this code.

Now, I would not want the above to be interpreted as a justification for not merging this code since I feel it would be a terrific addition to the kernel but I felt compelled to correct what I perceive as a misconception.

[thanks again for this terrific resource that I have been subscribed to for ... gasp ... 8 years now !?]