Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1261858 > unrolled thread

[RFC PATCH 00/28] Linux Kernel Library

Started byOctavian Purdila <octavian.purdila@intel.com>
First post2015-11-03 21:30 +0100
Last post2015-11-08 14:50 +0100
Articles 2 on this page of 42 — 7 participants

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 21/28] lkl tools: host lib: posix host operations Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
      Re: [RFC PATCH 21/28] lkl tools: host lib: posix host operations Arnd Bergmann <arnd@arndb.de> - 2015-11-08 00:20 +0100
        Re: [RFC PATCH 21/28] lkl tools: host lib: posix host operations Octavian Purdila <octavian.purdila@intel.com> - 2015-11-08 05:10 +0100
          Re: [RFC PATCH 21/28] lkl tools: host lib: posix host operations Arnd Bergmann <arnd@arndb.de> - 2015-11-08 11:40 +0100
    [RFC PATCH 18/28] lkl tools: host lib: virtio devices Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 19/28] lkl tools: host lib: virtio block device Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
      Re: [RFC PATCH 19/28] lkl tools: host lib: virtio block device Richard Weinberger <richard.weinberger@gmail.com> - 2015-11-07 13:30 +0100
        Re: [RFC PATCH 19/28] lkl tools: host lib: virtio block device Octavian Purdila <octavian.purdila@intel.com> - 2015-11-08 05:20 +0100
          Re: [RFC PATCH 19/28] lkl tools: host lib: virtio block device Richard Weinberger <richard@nod.at> - 2015-11-08 14:40 +0100
    [RFC PATCH 13/28] lkl: initialization and cleanup Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 20/28] lkl tools: host lib: filesystem helpers Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 24/28] lkl tools: tool that reads/writes to/from a filesystem image Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 22/28] lkl tools: "boot" test Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 02/28] kbuild: allow architectures to automatically define kconfig symbols Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 17/28] lkl tools: host lib: memory mapped I/O helpers Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 28/28] lkl tools: add support for Windows host Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 09/28] lkl: timers, time and delay support Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 16/28] lkl tools: host lib: add lkl_strerror and lkl_printf Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:30 +0100
    [RFC PATCH 01/28] asm-generic: atomic64: allow using generic atomic64 on 64bit platforms Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    [RFC PATCH 04/28] lkl: host interface Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
      Re: [RFC PATCH 04/28] lkl: host interface Hajime Tazaki <thehajime@gmail.com> - 2015-11-04 00:40 +0100
    [RFC PATCH 05/28] lkl: memory handling Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    [RFC PATCH 07/28] lkl: interrupt support Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    [RFC PATCH 06/28] lkl: kernel threads support Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    [RFC PATCH 03/28] lkl: architecture skeleton for Linux kernel library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-03 21:40 +0100
    Re: [RFC PATCH 00/28] Linux Kernel Library Richard Weinberger <richard.weinberger@gmail.com> - 2015-11-03 22:50 +0100
      Re: [RFC PATCH 00/28] Linux Kernel Library "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-03 23:50 +0100
        Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-04 00:30 +0100
          Re: [RFC PATCH 00/28] Linux Kernel Library Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-04 14:30 +0100
          Re: [RFC PATCH 00/28] Linux Kernel Library "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-04 15:00 +0100
            Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-04 15:30 +0100
              Re: [RFC PATCH 00/28] Linux Kernel Library Richard Weinberger <richard@nod.at> - 2015-11-07 01:40 +0100
                Re: [RFC PATCH 00/28] Linux Kernel Library "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-07 08:20 +0100
                Re: [RFC PATCH 00/28] Linux Kernel Library "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-07 11:50 +0100
                  Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-09 17:40 +0100
                Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-08 05:20 +0100
                Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-08 05:40 +0100
        Re: [RFC PATCH 00/28] Linux Kernel Library Hajime Tazaki <thehajime@gmail.com> - 2015-11-04 00:30 +0100
      Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-04 00:10 +0100
        Re: [RFC PATCH 00/28] Linux Kernel Library Octavian Purdila <octavian.purdila@intel.com> - 2015-11-09 16:20 +0100
    Re: [RFC PATCH 00/28] Linux Kernel Library Hajime Tazaki <thehajime@gmail.com> - 2015-11-08 14:50 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#1265759

FromOctavian Purdila <octavian.purdila@intel.com>
Date2015-11-09 16:20 +0100
Message-ID<qsWoF-89v-9@gated-at.bofh.it>
In reply to#1261950
On Sun, Nov 8, 2015 at 4:42 PM, yalin wang <yalin.wang2010@gmail.com> wrote:
>
> On Nov 4, 2015, at 07:06, Octavian Purdila <octavian.purdila@intel.com>
> wrote:
>
> On Tue, Nov 3, 2015 at 11:40 PM, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
>
> Hi Richard,
>
> On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila
> <octavian.purdila@intel.com> wrote:
>
> LKL (Linux Kernel Library) is aiming to allow reusing the Linux kernel code
> as extensively as possible with minimal effort and reduced maintenance
> overhead.
>
> Examples of how LKL can be used are: creating userspace applications
> (running on Linux and other operating systems) that can read or write Linux
> filesystems or can use the Linux networking stack, creating kernel drivers
> for other operating systems that can read Linux filesystems, bootloaders
> support for reading/writing Linux filesystems, etc.
>
> With LKL, the kernel code is compiled into an object file that can be
> directly linked by applications. The API offered by LKL is based on the
> Linux system call interface.
>
> LKL is implemented as an architecture port in arch/lkl. It relies on host
> operations defined by the application or a host library (tools/lkl/lib).
>
> The latest LKL version can be found at git@github.com:lkl/linux.git
>
>
> Or more copy&paste friendly: https://github.com/lkl/linux.git
>
> FAQ
> ===
>
> Q: How is LKL different from UML?
> A: UML provides a full OS environment (e.g. user/kernel separation, user
> processes) and also has requirements (a filesystem, processes, etc.) that
> makes it hard to use it for standalone applications. UML also relies
> heavily on Linux hosts. On the other hand LKL is designed to be linked
> directly with the application and hence does not have user/kernel
> separation which makes it easier to use it in standalone applications.
>
>
> So, this is a "liblinux" where applications are directly linked
> against the kernel.
> IOW system calls are plain function calls into the kernel?
>
>
> More like "thread" calls. All system calls are executed in a dedicate
> (kernel) thread to avoid race conditions with the "interrupt" path.
>
> why not call sys_XXX()  function directly?
> since kernel have implement lots of spin_locks to avoid race with normal
> path
> in IRQ handle ,  isn’t  it ?
> for example, you timer IRQ can be simulated by SIGALARM signal,
> and the signal handler can check if IRQ is disabled ,
> if not , then continuing , otherwise , return directly ..
> it is not safe ?
>

Hi Yalin,

We need to have a proper Linux context in order to issue system calls
(e.g. current needs to point to a proper Linux kernel thread_struct).
We also want to let the Linux scheduler to select what kernel threads
run at a given time. Lets say that currently a ksoftirqd runs and the
application want to issue a system call. In this case we want to wait
for ksoftirqd to complete then run the system call.

The simplest way I found to do that is to have the system calls
execute from Linux kernel threads hence the need to queue the system
calls from the application thread to the Linux kernel system call
thread.

(BTW, we can have multiple system call threads if needed and the 2.6
implementation has that, but in order to simplify the review process I
decided to throw away that for the moment).

Thanks,
Tavi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1265089

FromHajime Tazaki <thehajime@gmail.com>
Date2015-11-08 14:50 +0100
Message-ID<qsyw1-MG-7@gated-at.bofh.it>
In reply to#1261858
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web