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
