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