[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