Date: Wed, 22 Jan 2003 23:31:44 -0500 (EST) From: Garrett Wollman <wollman@lcs.mit.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: <arch@FreeBSD.ORG> Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301230431.h0N4ViJ6045184@khavrinen.lcs.mit.edu> In-Reply-To: <200301230416.h0N4GnRv017989@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <200301230259.h0N2xt9R017635@apollo.backplane.com> <200301230343.h0N3hfXt044969@khavrinen.lcs.mit.edu> <200301230416.h0N4GnRv017989@apollo.backplane.com>
index | next in thread | previous in thread | raw e-mail
<<On Wed, 22 Jan 2003 20:16:49 -0800 (PST), Matthew Dillon <dillon@apollo.backplane.com> said:
> (1) We don't have the kernel infrastructure to support it without a lot
> of hacks. i.e. we need a file-descriptor based vector array for
> high level descriptor based system calls in order to implement
> shm_open() properly in the kernel if we want to have any hope of
> keeping it compatible, or growing its compatibility, with other
> implementations.
You'd need to do that for any implementation of shared memory attached
to file descriptors; it's not a unique problem.
> (2) You are talking about a fairly complex API in its full glory. In
> its full glory shm_open() needs to deal with both private and public
> name spaces.
No, it doesn't. shm_open() knows nothing of `both private and public
name spaces'. The interpretation of the name of a shared memory
object is entirely left up to the implementation; the only requirement
is that all opens of "/foo" without an intervening unlink("/foo")
refer to the same object. *No other semantics are specified.* The
implementation is free to do anything it wishes with the names --
including what the current file-backed implementation does (which, you
will note, has no `private name space').
> As has been already discussed, some of the aspects of shm_open() do not
> lend themselves well to kernel implementation -- namely the private
> namespace support.
Again, there is no such thing as `private namespace support' in
shm_open() or any other POSIX IPC interface. You are reading
something into the standard that is simply not there.
-GAWollman
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301230431.h0N4ViJ6045184>