Hugh Dickins <[EMAIL PROTECTED]> wrote: > > > Under precisely what NOMMU conditions? > > > > CONFIG_MMU=n. > > Believe it or not, I had just about grasped that subtlety. I was > rather expecting some helpful response along the lines of "we share > all the vmas across a fork" or "whenever we go to allocate a vma, we > look to see if there's already an isomorphic vma which we can share" > or something like that. But don't worry about it, the source is > there for me to look at whenever.
Any VMAs that can be shared are, as a general rule. It works this way because shared MAP_PRIVATE read-only file data (such as a segment of an ELF executable) is stored in a kmalloc()'d buffer attached to the VMA. The lifetime of this buffer is handled by the VMA, and the buffer is not part of the pagecache. Maybe it could be; that'd make the ramfs handling more consistent with normal file handling. Such things as mappable chardevs do get separate VMA's, but those don't own the backing store. That's configured through the BDI information in the address_space. > > I can if it makes you happier. It's not strictly necessary, but it does > > make the struct smaller which is good. > > No, it doesn't really make me any happier: I expect that if I look any > deeper, I'll just find plenty more to worry about there. Good. I was hoping someone else would review it. > I have the impression, now reinforced by your defensive posture, *shrug* I was trying to keep the VMA as little changed as possible and add as little extra to it as possible. > that NOMMU is a hack that squeamish outsiders had better not look too deeply > into: Anyone that squeamish should avoid the full MMU VM like the plague then - it's way way worse. NOMMU is considerably simpler. Yes, some liberties have to be taken, but there's no avoiding that as there's no MMU available. I've tried to take as few as possible, and I've managed to make sure almost all the functionality afforded by the MMU kernels is available. > so long as it mostly works for those who need it to work, we'd probably just > be wasting your time anyway. *shrug* as you wish. David - 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/
