Hello Richard, Thanks for the review. On Sat, 26 Oct 2019 06:34:59 +0900, Richard Weinberger wrote: > > On Wed, Oct 23, 2019 at 6:39 AM Hajime Tazaki <thehajime@xxxxxxxxx> wrote: > > > > This RFC patchset is to ask opinions from UML people, whether LKL codes is > > good to integrate into UML code base. We wish to have any kind of feedback > > from your kind reviews. There are numbers of commits which should be asked > > for reviews to other mailing lists; we will do it later once we got > > discussed in this mailing list. > > Thanks a lot for doing this, this effort is much appreciated! :-) > > > # sorry for the long list of patches: we can make it smaller by only > > including basic set of LKL (e.g., removing foreign OS support, etc) if > > you wish. > > Let use see how the review goes. First I'll give it a high level review to make > sure we all talk about the same things. Thanks. > Please CC linux-arch@xxxxxxxxxxxxxxx for the next patch round. > Integrating LKL (into arch/um/) is something which needs more audience and > feedback from Arnd Bergmann, our global arch maintainer. Sure, will Cc. > > > > 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 originally implemented as an architecture port in arch/lkl, but this > > series of commits tries to integrate this into arch/um as one of the mode > > of UML. This was discussed during RFC email of LKL (*1). > > > > The latest LKL version can be found at https://github.com/lkl/linux > > > > Milestone > > ========= > > This patches is just a first step toward upstreaming *library mode* of > > Linux kernel, but we think we need to have several steps toward our goal, > > describing in the below. > > > > 1. Put LKL code under arch/um (arch/um/lkl), and build it in a > > separate way from UML. > > Makes sense. > > > 2. Share common parts of implementation between UML and LKL. > > Since both UML and LKL are usermode ports there is a lot of potential. > From my side it is also no big deal if there is some duplication which can be > resolved in later releases. Unifiing needs deep thoughts and miding odd corner > cases. I understand. > > 3. Reimplement UML features with LKL API (if we wish) > > Yep. In the last release UML got virtio support, so there is hope. ;-) Good news. > > For the step 1, we put LKL as one of SUBARCH in order to make less effort > > to integrate (make ARCH=um SUBARCH=lkl). The modification to existing UML > > code is trying to be minimized. > > I'm not sure if SUBARCH is the right approach. How do I build a i386 > lkl on x86_64? This is currently handled under tools/lkl: building arch/um/lkl part only requires toolchain information (e.g., CROSS_COMPILE=). So to build i386 liblkl.a, do `make ARCH=um SUBARCH=lkl`, which might not be intuitive.. > Maybe we can use another variable like UMMODE={library,kernel}? We will try to find this way to switch the mode instead. > > The RFC patches also includes and a bit of step 2 as a proof of possibility > > to share the code. For this, we used the virtio device code of LKL and use > > it from UML by enabling virtio-mmio driver with UML code. > > > > > > > > Building LKL the host library and LKL applications > > ================================================== > > > > % cd tools/lkl > > % make > > Is there a reason why tool/lkl is not under arch/um? I thought that this way makes clear distinction between host hardware/environment *dependent* (tools/lkl) part and *independent* (arch/um/lkl). We can rename it to tools/um instead. But if using new tools directory makes noisy, we would try to move those under arch/um. -- Hajime
