lkml.org 
[lkml]   [2015]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 00/28] Linux Kernel Library

Hello Octavian,

At Tue, 3 Nov 2015 22:20:31 +0200,
Octavian Purdila wrote:
>
>
> Q: How is LKL different from LibOS?
> A: LibOS re-implements high-level kernel APIs for timers, softirqs,
> scheduling, sysctl, SLAB/SLUB, etc. LKL behaves like any arch port,
> implementing the arch level operations requested by the Linux kernel. LKL
> also offers a host interface so that support for multiple hosts can be
> easily implemented.

I review most of code with the help of document and paper (2010).

I think LKL and LibOS are essentially the same thing.

I describe the current differences of both features, which I
believe there are no fundamental ones (i.e., both can
improve by putting some efforts).

- LKL
(beautiful) arch implementation (I like it)
fully kbuild compliant
rich fs support
host support: POSIX, win, haiku, etc

- LibOS
existing application integration
(semi-automated) system call table generation
multiple process support (via system call proxy)
various network backends (raw socket, DPDK, netmap, tap)
symbol namespace separation
host support: == rump hypercall (POSIX, xen,
qemu/kvm/baremetal(under development)), ns-3 simulator

# I can't find network support within the current patch but
there is/will be a certain code that LKL can play with
networking subsystem.

existing application integration is really important when
you want to configure network stack: since the configuration
of file systems is just a mount(), but configurations of
network stack need much userspace applications like iproute2
(ip, ss, tc) etc, which is not trivial to re-implement.


-- Hajime


\
 
 \ /
  Last update: 2015-11-08 15:01    [W:0.241 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site