On Fri, 24 Jul 2026 15:49:08 +0900, Johannes Berg wrote: > > On Fri, 2026-07-24 at 15:20 +0900, Hajime Tazaki wrote: > > > UML models this with > > > +a **userspace runner** - an ordinary uml-userspace stub host process, > > > started > > > +exactly like an MMU userspace process, but with the whole of "physical" > > > memory > > > +(the physmem file) mapped into it at the kernel's addresses: > > > + > > > +- The runner ``exec()``'s the stub just like the MMU case. The only > > > extra step > > > + is that, once it is up, the kernel maps the entire physmem file into > > > it in one > > > + go, at the same addresses the kernel uses. > > > +- Because NOMMU never remaps, that single mapping is all a runner ever > > > needs: > > > > I was actually not sure what you mean here: "NOMMU never remaps". > > could you care to elaborate ? > > the subsequent parts are clear to me. > > Yeah maybe, that's a bit cryptic. I mean, we have an MMU-less base > kernel, so there's never any request to remap for anything, so > > > > + there is no per-mm host process, no TLB sync and no ``mmap()`` of > > > individual > > > + page-table entries into a child. Userspace code and data - placed in > > > memory > > > + by the loader - are directly executable and accessible. > > the original mapping that we make into that process is left alone > forever. The map machinery in the stub is used only exactly once.
make sense to me, thanks. > > For the alpine packages, I'll contact the distribution once this UML > > is upstreamed. And update this part with more proper information > > rather than my personal repository. > > Sure. It seemed far simpler to point to it than to try to have > instructions on how to build it (I didn't even try), and I'm assuming > you don't plan to remove it :) I will keep this image location but using version number will easily outdate while it's useful to present a snapshot for users. -- Hajime
