On Fri, Nov 22, 2024 at 10:53:18AM +0100, Johannes Berg wrote: > On Fri, 2024-11-22 at 09:33 +0000, Lorenzo Stoakes wrote: > > > > In general, while I appreciate your work and don't mean to be negative, we > > in mm consistently have problems with nommu as it is a rarely-tested > > more-or-less hack used for very few very old architectures and a constant > > source of problems and maintenance overhead for us. > > > > It also complicates mm code and time taken to develop new features. > > > > So ideally we'd avoid doing anything that requires us maintain it going > > forward unless the benefits really overwhelmingly outweigh the drawbacks. > > :) > > There aren't really any benefits to ARCH=um in *itself*, IMHO. > > > There have been various murmourings about moving towards elimination of > > nommu, obviously this would entirely prevent that. > > No objection from me, but e.g. RISC-V added nommu somewhat recently? > (+Christoph, Damien) I mean it's not my place to object to this of course, but ideally we'd avoid supporting the truly low spec RISC-V arches which do not have MMUs (I wasn't aware there were some but I am wholly unfamiliar with RISC-V so plead ignorance!) > > So we could argue the other way around and say that while we have other > architectures with nommu (like RISC-V), having ARCH=um could simplify > testing by e.g. allowing a kunit configuration in ARCH=um which is > simpler (and probably faster) to run for most people than simulating a > foreign architecture. Yeah and this is the flip side of the coin, I mean it's actually very useful to be able to test nommu stuff easily (I've had real issues getting nommu m68k working in qemu for instance), but my concern is by adding more dependency on this mechanism it makes it harder to remove later. I would support this if in future there wouldn't be too much objection to _this_ feature being removed should we come to a point where nommu removal happens. If a large part of the motivation is testing nommu arches, and we at some point eliminate them, then I think hopefully given this would in that case be the raison d'etre for the effort it'd not be too egregious to remove at this point. In which case, the flip side of the coin is that I am in fact positive about the testing possibilities here :) > > Anyway, I think that's where I am with my partial (and very limited) > ARCH=um maintainer role. I don't really care for having the feature in > UML itself, but if it's useful for testing nommu architectures for > someone else, it doesn't seem too problematic to support. And testing > such things is also a big part of the argument Hajime was making, > afaict. > > johannes > Thanks, and again I don't mean to be negative or difficult about this series, I just want to raise the fact that 'in the wind' so to speak there is desire to eliminate nommu at some point. How realistic that desire is, I am not sure... Cheers, Lorenzo
