lkml.org 
[lkml]   [2000]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: thread rant
From
Date
Alexander Viro <viro@math.psu.edu> 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
VFS.
3) SYSV shm should only be a special API using this functionality

Comments?
Christoph

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.825 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site