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

Johannes Berg johannes at sipsolutions.net
Wed Jul 22 00:46:31 PDT 2026


Hi,

> thanks, this is really nice.

Thanks for looking!

> I quickly read the patchset and found that [RFC PATCH 8/9] is the core
> of your idea,

Right, of course. There's a bunch of prep work, and I obviously picked
up a bunch of your prep work too.

> I also understand the need of futex implementation instead of
> asm-generic, which only works with !CONFIG_SMP.

Right.

>   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.

> 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.

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

> 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.

johannes



More information about the linux-um mailing list