[PATCH v2 10/10] Documentation: um: document nommu UML

[Johannes Berg]

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.

> 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 :)

johannes