Return-Path: Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lMtSw-005T0l-PU for linux-um@lists.infradead.org; Thu, 18 Mar 2021 14:17:39 +0000 Received: by mail-pg1-x535.google.com with SMTP id m3so1524665pga.1 for ; Thu, 18 Mar 2021 07:17:34 -0700 (PDT) Date: Thu, 18 Mar 2021 23:17:36 +0900 Message-ID: From: Hajime Tazaki Subject: Re: [RFC v8 00/20] Unifying LKL into UML In-Reply-To: <8c6f4ba994831b55ce7893f7e8e71a614474b907.camel@sipsolutions.net> References: <8c6f4ba994831b55ce7893f7e8e71a614474b907.camel@sipsolutions.net> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: johannes@sipsolutions.net Cc: tavi.purdila@gmail.com, linux-um@lists.infradead.org, jdike@addtoit.com, richard@nod.at, anton.ivanov@cambridgegreys.com, linux-kernel-library@freelists.org, linux-arch@vger.kernel.org, retrage01@gmail.com 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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um