Re: [RFC PATCH 00/47] Unifying LKL into UML

[Hajime Tazaki <thehajime@gmail.com>]

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@gmail.com> 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@vger.kernel.org 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