Date: Wed, 22 Jan 2003 18:01:49 -0500 (EST) From: Garrett Wollman <wollman@lcs.mit.edu> To: jroberson@chesapeake.net Cc: arch@FreeBSD.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301222301.h0MN1nHg043396@khavrinen.lcs.mit.edu> In-Reply-To: <20030122173229.D46974-100000@mail.chesapeake.net> References: <200301222144.h0MLifiC009829@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article <20030122173229.D46974-100000@mail.chesapeake.net> you write:
>I think the argument is for fixing the implementation of shm_open() such
>that it supports this feature and move it into kernel space. Such that if
>you use a key preceded by a '/' it will use the filesystem as the
>namespace and otherwise it will be local and swap backed.
There is no reason to have more than one namespace. Indeed, doing so
would only complicate matters. Just interpret the path name like a
path name. As I mentioned before, you need to have reasonable
access-control and naming semantics, and using the filesystem for that
purpose is both natural and avoids unnecessary duplication. Want a
unique name? We've got a whole pile of library functions which can do
that. (If you do not need a name, then you don't need a shared-memory
object, you need anonymous shared memory, which is already
implemented.)
The object in the filesystem is only a rendezvous point for the shared
memory object; it is not the object itself. The only requirement on
the part of the Standard is that two calls to shm_open("/foo", ...)
must refer to the same shared memory object, provided of course that a
call to shm_unlink("/foo") has not intervened. There is no, repeat NO
requirement that the object have any sort of backing store, much less
use the file system for that purpose. The current implementation of
shm_open() does that, because it was easy to implement that way. A
better implementation would probably not do so.
What I am arguing against is the creation of yet another FreeBSD-only
interface when the needs of applications can be met by a better
implementation of a standard interface that we already have.
- -GAWollman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)
iD8DBQE+LyLcI+eG6b7tlG4RAkzwAKCM9YO9LKfSmwGxH5NIEyG77xgEiQCgpOmU
Xf+Zt9yNwKUgGfA3BfTwFmg=
=Keks
-----END PGP SIGNATURE-----
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301222301.h0MN1nHg043396>