Hello,

On Wed, 17 Mar 2021 23:24:14 +0900,
Johannes Berg wrote:

Hi,

quoted

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.

quoted

quoted

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.

quoted

quoted

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/

quoted

quoted

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