On Mon, 2024-11-11 at 15:27 +0900, Hajime Tazaki wrote: > This is a series of patches of nommu arch addition to UML. It would > be nice to ask comments/opinions on this.
So I've been thinking about this for a while now... To be clear, I'm not really _against_ it. With around 1200 lines of code, it really isn't even big. But I also don't know how brittle it is? Testing it is made somewhat difficult with the map-at-zero requirement too. And really I keep coming back to asking myself what the use case is? Is it to test something for no-MMU platforms more easily? But I'm not sure what that would be? Have any no-MMU platform maintainers weighed in on this, have they even _seen_ it? Is that interesting? Is it more interesting than testing an emulated system with the right architecture? With it this way you'd probably have to build the right libraries and binaries for x86-64 no-MMU, does such a thing already exist somewhere? It also doesn't look like it's meant to replace LKL? But even LKL I don't really know - are people using it, and if so what for? Seems lklfuse is a thing for some BSD folks? Is there something else to use it for? If it's the first (test no-MMU) then it probably should be smarter about not really relying on retpoline. Why is the focus so much on that anyway? If testing no-MMU was the most important thing then probably you'd have started with seccomp, and actually execute the syscalls from that, to not have all those restrictions that come from rewriting binaries, rather than ignoring the whole thing. Though of course you did add a filter now, but I think it'll just crash? So I could perhaps see this use case, but then I'd probably think it should be more generic (i.e. able to execute all no-MMU binaries including ones that may be using JIT compilation etc.) and not _require_ retpoline, but rather use it as an optimisation where that's possible (i.e. if you can map at zero)? If the use case instead of more LKL-type usage, I guess I don't really understand it, though to be honest I also don't really fully understand LKL itself, but it always _seemed_ very different. Somewhat hyperbolically, I'm wondering if it's just a tech demo for retpoline? So I dunno. Reading through it again there are a few minor things wrt. code style and debug things left over, but it's not awful ;-) I'd also prefer the code to be more clearly "marked" (as nommu), perhaps putting new files into a nommu/ directory, or something like that. But that's pretty minor. Still it's in a lot of places and chances are it'll make bigger refactoring (like seccomp mode) harder. Perhaps if at all it should come after seccomp mode and use that to execute syscalls if zpoline can't be done, and to catch all the cases where zpoline doesn't work (you have that in the docs)? What do others think? Would you use it? What for? johannes