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

[Johannes Berg <johannes@sipsolutions.net>]

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.

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.


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!