On Wed, Nov 4, 2015 at 12:45 AM, Richard W.M. Jones <rjo...@redhat.com> wrote: > On Tue, Nov 03, 2015 at 10:40:29PM +0100, Richard Weinberger wrote: >> On Tue, Nov 3, 2015 at 9:20 PM, Octavian Purdila >> <octavian.purd...@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 g...@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? >> >> 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. :-) > > Thanks - I was keeping an eye on libos (and on the NetBSD rump kernel > stuff before), ready to integrate them into libguestfs as soon as they > offered filesystem access. > > It's easy to write a libguestfs-compatible backend, which brings all > the virt-* tools from libguestfs to the new code. The UML one looks > like this: > > https://github.com/libguestfs/libguestfs/blob/master/src/launch-uml.c >
Thanks for the pointers Richard, I am going to take a look at it. > > I'm dubious that a lib-based approach could support LVM, partioning, > ntfs-3g, qcow2, vmdk and all the other libguestfs stuff that relies on > userspace tools + qemu as well as just the kernel drivers. > Nevertheless a fast subset of libguestfs supporting just kernel > filesystem drivers could be useful. > LKL uses the full Linux I/O stack and I think LVM and partitioning should work out of the box. Adding support for qcow2 and vmdk should be possible as well. ntfs-3g might be problematic. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
