Re: [RFC v4 02/25] um lkl: architecture skeleton for Linux kernel library

[Richard Weinberger <richard.weinberger@gmail.com>]

Johannes, Hajime,

On Mon, Mar 30, 2020 at 11:53 PM Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> On Mon, 2020-03-30 at 23:45 +0900, Hajime Tazaki wrote:
> > From: Octavian Purdila <tavi.purdila@gmail.com>
> >
> > Adds the LKL Kconfig, vmlinux linker script, basic architecture
> > headers and miscellaneous basic functions or stubs such as
> > dump_stack(), show_regs() and cpuinfo proc ops.
> >
> > The headers we introduce in this patch are simple wrappers to the
> > asm-generic headers or stubs for things we don't support, such as
> > ptrace, DMA, signals, ELF handling and low level processor operations.
> >
> > The kernel configuration is automatically updated to reflect the
> > endianness of the host, 64bit support or the output format for
> > vmlinux's linker script. We do this by looking at the ld's default
> > output format.
>
> Can you elaborate what the plan is here?
>
> I mean, you're not actually "unifying" anything with ARCH=um, you're
> just basically splitting ARCH=um into ARCH=um-um and ARCH=um-lkl or
> something. Is there much point?
>
> Even the basic underlying building blocks are _very_ different, e.g. in
> UML the host interface is just a bunch of functions that must be
> implemented (os_*()), while you have a "struct lkl_host_operations". If
> we can't even unify at that trivial level, is there any point in it at
> all? I'm not even really sure what those ops are used for - are all of
> those things that the *application* using LKL necessarily must provide?
>
> Similarly with the IRQ routing mechanism - two completely different
> concepts. Where's the "unifying"?
>
> Ultimately, I can see two ways this goes:
>
> 1) We give up, and get ARCH=lkl, sharing just (some of) the drivers
>    while moving them into the right drivers/somewhere/ place. Even that
>    looks somewhat awkward looking at the later patches in this set, but
>    seems like that at *least* should be done.

Yeah, this would be a goal.
UML and LKL are quite different but they should share at least their userspace
drivers.
I also don't mind if we don't share every driver at the beginning but
it should be
a feasible goal for the future.

> 2) Ideally, instead, we actually unify: LKL grows support for userspace
>    processes using UML infrastructure, the "in-kernel" IRQ mechanisms
>    are unified, UML stuff moves into lkl-ops, and the UML binary
>    basically becomes a user of the LKL library to start everything up.
>    There may be some bits remaining that are just not interesting (e.g.
>    some drivers you don't care about would continue to make direct calls
>    to the user side instead of lkl-ops, and then they're just not
>    compatible with lkl, only with the uml special case of lkl), but then
>    things are clean.

A few months ago I though this is doable but now I'm not so sure anymore.

>
> Now, of course it seems like (2) would actually be better - LKL would
> actually get support for userspace processes using UML's tricks, most of
> the code is unified, and even LKL's users can take advantage of new
> things. At the same time, all of the duplication is avoided.
>
> However, I just don't know if it's actually _possible_ to do that
> though. Conceptually, it seems like it should be - why shouldn't a
> library be able to spawn other userspace processes - I mean, it's not
> really in the model that LKL really _wants_ since it's supposed to offer
> the syscall API, but you could make a "bool run_normal_init" or
> something in the lkl-ops for the user of the library to determine what
> should happen, right?
>
> However, there clearly are huge differences between LKL and UML in all
> respects, and I don't know if this wouldn't conflict with the library
> model, e.g. there may be linker issues etc. Or maybe the specific UML
> interrupt handling is required in UML and cannot be done in LKL (but
> then perhaps it could be put into the hypothetical UML-application vs.
> UML-the-LKL-library?)
>
>
> Ultimately, personally I think it's going to have to be one or the other
> of those two options though, I don't really see much value in what
> you're doing here in the patchset now. This way just messes up
> everything, it's not clear what's UML and what's LKL, and they're
> intertwined with ifdefs everywhere; just look at where you have to add
> ifdefs in patch 23 - how would anyone later understand which part gets
> compiled for which of them?
>
> johannes
>
> PS: actually having something like lkl-ops in UML would've been nice
> also for my "time-travel" work, since it neatly abstracts the timers
> out. I do wonder a bit about the overhead of jumping through function
> pointers all the time though, it may be worth rethinking that overall
> anyway!

Agreed. UML can also learn from LKL. :-)

-- 
Thanks,
//richard