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

[Hajime Tazaki]

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