Re: [RFC PATCH 0/9] simplified UML/NOMMU approach

Hello,
# +Cc: Lorenzo, Liam,

On Wed, 22 Jul 2026 16:46:31 +0900,
Johannes Berg wrote:

> >   um-nommu(seccomp)        3533 
> >   um-nommu-skas           27844
> >   um-nommu-skas(seccomp)  26387
> 
> I'm a bit surprised these have such a huge difference, do you see any
> obvious explanation for that?
> 
> But I'm also still not really convinced that it matters at all.

I have explained this in the message below:

https://lore.kernel.org/all/[email protected]/

# was also covered in my netdevconf talk but in a backup slide.
https://speakerdeck.com/thehajime/nommu-uml-netdev-0x1a?slide=28

> > What is your plan for this RFC ?
> 
> Well, first I wanted to hear what you think :-)

:)

> > I'm pretty fine with this (skas nommu) mode for nommu UML; it
> > is certainly useful to detect more bugs if it is available in UML.
> 
> Yeah, that was mostly my intent - to show a path forward for the nommu
> (kunit) testing in UML, without all the other complexity.

understand.

> > I would also like to ask maintainers if my nommu approach can be an
> > opt-in feature only when specific kernel config is added, probably
> > marking as '(EXPERIMENTAL)' or `if EXPERT` condition, as there is
> > potential benefits (speed, less host process use, etc.).
> > 
> > But if you (maintainers) wish and feel this as not an easy option,
> > I can work for it with later patches as an extension.
> 
> Personally, I've always mostly thought that there isn't really a good
> use case (or perhaps that you haven't really convinced me of one) that
> actually requires the speed benefit, but I guess I can't really decide
> that by myself. :)

understand too.

actually one of my motivation to give a talk at netdevconf was to
present a use-case of the speed benefit.

but I'd like to rephrase this motivation in a different thread; I wish
to move forward nommu UML as mm folks (cc-ed) might think it's useful.

> > btw, maybe I need a better name for (my) nommu code using different
> > syscall handling, with regard to skas (i.e., separate kernel address
> > space) mode (e.g., CONFIG_UML_NOMMU_SAS (single address space) etc.).
> 
> Oh, I didn't even remember now that "skas" was meant to mean "separate
> kernel address space". To me this is all a quirk of history ... we
> probably shouldn't read too much into it now.

Personally, I think skas still does make sense from the host address
space pov;  uml kernel and uml-userspace processes are in different
address space.

that's what I meant in CONFIG_UML_NOMMU_SAS in my previous email.

-- Hajime