On Tue, Nov 3, 2015 at 11:40 PM, Richard Weinberger <richard.weinberger@xxxxxxxxx> wrote: Hi Richard, > On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila > <octavian.purdila@xxxxxxxxx> 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@xxxxxxxxxx: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. > This eliminates UML's most problematic areas, system call handling via ptrace() > and virtual memory management via SIGSEGV. :-) > :) >> 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. > > Yeah, these re-implementations are what I find most worrisome about LibOS. > >> >> Building LKL the host library and LKL applications >> ================================================== >> >> % cd tools/lkl >> % make >> >> will build LKL as a object file, it will install it in tools/lkl/lib together >> with the headers files in tools/lkl/include then will build the host library, >> tests and a few of application examples: >> >> * tests/boot - a simple applications that uses LKL and exercises the basic >> LKL APIs >> >> * fs2tar - a tool that converts a filesystem image to a tar archive >> >> * cptofs/cpfromfs - a tool that copies files to/from a filesystem image > > Seeing forward to have a libguestfs port. :-) > > Is LKL strictly single threaded? > At this point yes. SMP support is on my todo list though :) -- 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
