Alexander Viro <firstname.lastname@example.org> writes:
> On Sat, 2 Sep 2000, Ingo Molnar wrote:
> > well, Linux SysV shared memory indeed has a 'software version' of
> > pagetables, this way if one process faults in a new page (because
> > all pages are unmapped originally), then the new physical page
> > address can be discovered by all other subsequent faults in other
> > process contexts. It works just fine - the thing i dislike about
> > SysV shared memory is not the VM part but its 'filesystem
> > characteristics' - i think anonymous shared memory is the way to
> > go.
> Why? I would say that bad thing about SysV shared memory is that
> it's _not_ sufficiently filesystem-thing - a special API where
> 'create a file on ramfs and bloody mmap() it' would be
> sufficient. Why bother with special sets of syscalls?
Yes, and that's what I plan for 2.5: Redoing the shm filesystem part
like (or in?) ramfs and better separation of both the VM part and the
SYSV API part.
I always objected against doing anonymous shared mmap over SYSV shared
mem because I wanted to have this handling in the VM layer and _not_
in some horrible^wspecial API layer.
So my goal would be:
1) anonymous shared mappings should be handled by the vm layer (with
better integration into the pagecache)
2) the filesystem frontend should be redone to make more use of the
3) SYSV shm should only be a special API using this functionality
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:13 EST