* Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> [250425 06:45]: ... > > > > > > > > I think doing it this way fits the patterns we have established for > > > > nommu/mmap separation, and I would say nommu is enough of a niche edge case > > > > for us to really not want to have to go to great lengths to find ways of > > > > sharing code. > > > > > > > > I am quite concerned about us having to consider it and deal with issues > > > > around it so often, so want to try to avoid that as much as we can, > > > > ideally. > > > > > > I think you're asking for more issues the way you have it now. It could > > > be a very long time until someone sees that nommu isn't working, > > > probably an entire stable kernel cycle. Basically the longest time it > > > can go before being deemed unnecessary to fix. > > > > > > It could also be worse, it could end up like the arch code with bugs > > > over a decade old not being noticed because it was forked off into > > > another file. > > > > > > Could we create another file for the small section of common code and > > > achieve your goals? > > > > That'd completely defeat the purpose of isolating core functions to vma.c. > > > > Again, I don't believe that bending over backwards to support this niche > > use is appropriate. > > > > And if you're making a change to vm_area_alloc(), vm_area_free(), > > vm_area_init_from(), vm_area_dup() it'd seem like an oversight not to check > > nommu right? > > > > There's already a large amount of duplicated logic there specific to nommu > > for which precisely the same could be said, including entirely parallel > > brk(), mmap() implementations. > > > > So this isn't a change in how we handle nommu. > > I guess an alternative is to introduce a new vma_shared.c, vma_shared.h > pair of files here, that we try to allow userland isolation for so vma.c > can still use for userland testing. > > This then aligns with your requirement, and keeps it vma-centric like > Suren's suggestion. > > Or perhaps it could even be vma_init.c, vma_init.h? To denote that it > references the initialisation and allocation, etc. of VMAs? Sure, the name isn't as important as the concept, but I like vma_init better than vma_shared. > > Anyway we do that, we share it across all, and it solves all > problems... gives us the isolation for userland testing and also isolation > in mm, while also ensuring no code duplication with nommu. > > That work? Yes, this is what I was suggesting. I really think this is the least painful way to deal with nommu. Otherwise we will waste more time later trying to fix what was overlooked. Thanks, Liam
