Re: [PATCH] mm: nommu: point to the write iterator upon split_vma

[Hajime Tazaki]

Hello Lorenzo,

On Wed, 08 Jul 2026 04:15:53 +0900,
Lorenzo Stoakes wrote:

> > as nommu started for embedded devices which are not easy to test, I
> > agree that it is also not easy (in my opinion) to maintain.
> 
> Indeed.
> 
> >
> > indeed, buildroot images for nommu targets (with qemu) are available,
> > but running/testing each of commit to the kernel tree give me more
> > than 1 hour to rebuild the images (including userspace build with long
> > flat binary conversion, etc) (which I'm playing under github actions
> > with riscv-nommu).
> 
> I've struggled to even get the buildroot images to work in any way. Right now I
> don't have a clear nommu test setup other than building nommu_virt_defconfig for
> riscv.
> 
> >
> > # yes, should use ccache :)
> 
> :))
> 
> >
> > one of the goal which I am with nommu UML (*1) is to provide an
> > environment which can be tested in a simple way; runs on x86
> > machines.  An extension to UML means that you can also use KUnit
> > infrastructure.
> 
> Yeah.
> 
> Well indeed my raising the 'please let us pull this out' was initially a push
> back on that, because if we were going to pull it then that work would work
> against it, but then it became clear that that dream wasn't possible.
> 
> And that makes your work on that REALLY REALLY USEFUL :) so do cc me and ping me
> on any respin and I'll try to find time to help.

thanks, will cc from next spin.

> >
> > LTP (Linux Test Project) dropped the nommu tests 2 years ago (*2)
> > (which is pity), but the reason is similar: no maintainers appeared
> > when the project asked.
> 
> Yeah and it's just the same thing overall with all of this.
> 
> The companies who are apparently dependent on this need to _actually pay people
> to do some even rudimentary testing_.
> 
> nommu.c is co-maintained by me and Liam simply because we have done more to fix
> issues with it than nearly anybody else recently. It's just a burden that we
> took on.
> 
> I'd far rather see an invested mm person take over if we do indeed have to live
> with it :)
> 
> I also wonder if we couldn't find a way to implement it in a more maintainable
> way, perhaps as a 'virtual' mmu system somehow?
> 
> I simply don't have the bandwidth for that myself, unfortunately.

If you meant that 'a way to implement it in a more maintainable' is
about the code structure, the current nommu.c is reasonably
abstracted, which contributes a bit to reduce the maintenance burden.

I thought that what missing is a resource of tests and eyes to look at
those test results.

I agree that the tests should be done by the people who are using the
code.  Moreover (and ideally), the code should be maintained by the
people who're using.
I think I can help at least the former part.  For the latter part, I
wish to help as well but I'm still a very immature developer of mm
subsystem (who struggled with addressing Sashiko reviews...).

> > I wish to be here to improve this situation, both mm/nommu subsystem
> > and LTP, as well as any !CONFIG_MMU code in kernel tree.  This patch
> > is actually discovered during LTP (re-)integration with nommu kernel,
> > which I'm going to propose to LTP.
> 
> Your work is appreciated and welcome, thank you! :)
> 
> >
> > I hope this helps a bit.
> 
> You're definitely helping here and again, much appreciated!

m(_ _)m

-- Hajime