Re: [PATCH] get rid of vm_private_data and win posix shm

Linus Torvalds (torvalds@transmeta.com)
28 Dec 1999 11:14:34 -0800


In article <qwwd7rrgeen.fsf@sap.com>,
Christoph Rohland <hans-christoph.rohland@sap.com> wrote:
>
>I implemented posix shm with its own namespace by extending filp_open
>and do_unlink by an additional parameter for the root inode.

Beautiful patch _except_ for this case. I'm really pleased with how well
the POSIX shm code seems to integrate into the FS and VM layers, and
that makes me happy.

The one imbalance you added makes me cringe, though. I think we should
just export it as a real filesystem, and mount it in a standard
location. Nothing clever, just come up with a new location that is
fixed and acceptable to all, kind of like /proc is now.

That has the added advantage that you can eventually write scripts with
perl etc to look at shared memory regions etc, without having to add new
magic system calls.

So how about standardizing on a base path called "//posix/shm"? Right
now that is the same as "/posix/shm", but leave the double slash there
in the utilities and library routines, because maybe we'll end up using
the POSIX-approved "initial double slash is special" rule at some point
in the future. So we can initially mount it as a regular mount-point,
and then in the future maybe extend the notion of '//'-paths to be more
of a "virtual filesystem" thing without breaking backwards
compatibility.

And don't worry about making "readdir()" and friends work yet - a
minimalistic shm filesystem that only knows "lookup", "create" and
"unlink" is fine, with the nice finishing touches can be left for
later..

Linus

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