[RFC v8 00/20] Unifying LKL into UML

[Hajime Tazaki]

Hello,

On Wed, 17 Mar 2021 23:24:14 +0900,
Johannes Berg wrote:
> 
> Hi,
> 
> > One use case where this matters are non OS environments such as
> > bootloaders [1], running on bare-bone hardware or kernel drivers [2,
> > 3]. IMO it would be nice to keep these properties.
> 
> OK, that makes sense. Still, it seems it could be a compile-time
> decision, and doesn't necessarily mean LKL has to be NOMMU, just that it
> could support both?
> 
> I'm really trying to see if we can't get UML to be a user of LKL. IMHO
> that would be good for the code, and even be good for LKL since then
> it's maintained as part of UML as well, not "just" as its own use case.
>
> > > If your abstraction was instead "switch context" then you could still
> > > implement it using pthreads+mutexes, or you could implement it using
> > > fibers on windows, or posix contexts - but you'd have a significantly
> > > reduced API surface, since you'd only expose __switch_to() or similar,
> > > and maybe a new stack allocation etc.
> > 
> > You are right. When I started the implementation for ucontext it was
> > obvious that it would be much simpler to have abstractions closer to
> > what Linux has (alloc, free and switch threads). But I never got to
> > finish that and then things went into a different direction.
> 
> OK, sounds like you came to the same conclusion, more or less.
>
> > > Additionally, I do wonder how UML does this now, it *does* use setjmp,
> > > so are you saying it doesn't properly use the kernel stacks?
> > > 
> > 
> > To clarify a bit the statement in the paper, the context there was
> > that we should push the thread implementation to the
> > application/environment we run rather than providing "LKL" threads.
> > This was particularly important for running LKL in other OSes kernel
> > drivers. But you are right, we can use the switch abstraction and
> > implement it with threads and mutexes for those environments where it
> > helps.
> 
> Right - like I pointed to USFSTL framework, you could have posix
> ucontext, fiber and pthread at least, and obviously other things in
> other environments (ThreadX anyone? ;-) )

I also have an idea for a ThreadX in future, which also implements
actual context in the application/environment/host side (not in kernel
side, as others do).  Though this environment may not provide
mprotect-like features, there is still a value that the application
can run Linux code (e.g., network stack) for instance.

# This story is about our old work of network simulation.
  https://lwn.net/Articles/639333/

> > > But conceptually, why wouldn't it be possible to have a liblinux.so that
> > > *does* build with MMU and userspace support, and UML is a wrapper around
> > > it?
> > > 
> > 
> > This is an interesting idea. Conceptually I think it is possible.
> > There are lots of details to be figured out before we do this. I think
> > that having a NOMMU version could be a good step in the right
> > direction, especially since I think a liblinux.so has more NOMMU
> > usecases than MMU usecases - but I haven't given too much thought to
> > the MMU usecases.
> 
> Yeah, maybe UML would be the primary use case. I have been thinking that
> there would be cases where you could combine kunit and having userspace
> though, or unit-style testing but not with kunit which is "inside" the
> kernel, but instead having the test code more "outside" the test kernel.
> That's all kind of handwaving though and not really that crystallized in
> my mind.
> 
> That said, I'm not entirely sure NOMMU would be the right path towards
> this - if we do want to go this route it'll probably need changes in
> both LKL and UML to converge to this point, and at least build it into
> the abstractions.
> 
> For example the "idle" abstraction discussed elsewhere (is it part of
> the app or part of the kernel?), or the thread discussion above (it is
> part of the app but how is it implemented?) etc.

I agree that LKL (or the library mode) can conceptually offer both
NOMMU/MMU capabilities.

I also think that NOMMU library could be the first step and a minimum
product as MMU implementation may involve a lot of refactoring which
may need more consideration to the current codebase.

We tried with MMU mode library, by sharing build system
(Kconfig/Makefile) and runtime facilities (thread/irq/memory).  But,
we could only do share irq handling for this first step.

When we implement the MMU mode library in future, we may come up with
another abstraction/refactoring into the UML design, which could be a
good outcome.  But I think it is beyond the minimum given (already)
big changes with the current patchset.

-- Hajime