On Fri, 9 Mar 2007, David Howells wrote: > > I've been considering how to deal with the SYSV SHM problem, and I think we > may have to move to unshared VMAs in NOMMU mode to deal with this. Currently, > what we have is each mm_struct has in its arch-specific context argument a > list of VMLs. Take the FRV context for example: >... > Another way of dealing with the nattch count on NOMMU systems is to do it > through the VML list, but that then needs more special casing in the SHM > driver and perhaps others. > > Thoughts?
Thoughts are in regrettably short supply at my end. I do appreciate all the trouble you've taken to explain it, in terms I'd understand. And the way you've taken on board my anxiety about vma assumptions diverging between NO/MMU. But if "the SYSV SHM problem" you mention at the beginning is just the "nattch" problem you mention at the end, I doubt that's worth such a redesign as you're considering here. Actually, I'm rather surprised SHM needs any such nattch count, I'd expect it to deducible from file->f_count and mode&SHM_DEST (but haven't investigated whether that really works out at all). If you just need a little CONFIG_MMU in ipc/shm.c to solve your problem, I don't think more is justified. Your struct vm_region idea does look more to my taste than what you presently have; yet if you pursue it, I think it would just make divergence worse wouldn't it? NOMMU wanting vma to contain a pointer to vm_region, MMU wanting vm_region embedded in vma. I don't really understand why NOMMU chooses to share vmas, or vm_regions, rather than just sharing the data which they indicate. Just because you can use less memory that way? But no need to justify it now, I'm unlikely to study it in detail. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/