Date: Wed, 22 Jan 2003 23:12:17 -0500 (EST) From: Garrett Wollman <wollman@lcs.mit.edu> To: Peter Wemm <peter@wemm.org> Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301230412.h0N4CHFI045123@khavrinen.lcs.mit.edu> In-Reply-To: <20030123033918.DE9372A7EA@canning.wemm.org> References: <200301230313.h0N3DmPP044886@khavrinen.lcs.mit.edu> <20030123033918.DE9372A7EA@canning.wemm.org>
index | next in thread | previous in thread | raw e-mail
<<On Wed, 22 Jan 2003 19:39:18 -0800, Peter Wemm <peter@wemm.org> said:
> Sigh. It is in the beginning of this thread, before it changed name.
> Search for the subject containing "Virtual memory question" from around
> January 11th. The original subject lives on in brackets.
> The first message-id is <20030111224444.94D102A89E@canning.wemm.org>,
> and there is quite a bit of elaboration afterwards.
OK, I found it in the archives. Assuming a swap-backed implementation
of shm_open(), the way to get what you want would be very simple:
fd = shm_open("/foo", O_RDWR | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
shm_unlink("/foo");
ftruncate(fd, size_required);
mmap(...);
...that's using only standard interfaces.[1] As an extension, we could
dispense with the naming entirely:
// cons up a unique unnamed shared memory object
// it doesn't really matter what the permissions are since the only
// reference to it is through `fd'; however, we have to at least
// specify enough permission bits to allow ourself to open it
fd = shm_open("", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
ftruncate(fd, size_required);
mmap(...);
"" is not really a valid pathname, but I think it's safer to use the
empty string to invoke an extension like this than to use a null
pointer.
-GAWollman
[1] The standard does not completely specify the semantics of the name
of a shared memory object. The name is required to meet the syntax of
a pathname. However, it neither requires nor prohibits the implementation
interpreting the name as a pathname. In 1999, Stevens found that some
implementations, such as DEC's, required that the name be a valid
pathname (of an existing file or one that the user would have
sufficient privilege to create); other implementations, like Sun's,
required that the name contain exactly one slash (they would then
create a rendezvous file of the form "/tmp/goop.foo" for the name
"/foo" for all values of "foo" including ones containing slashes).
The consensus seems to be that the former implementation is more
useful, and certainly more secure.
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?200301230412.h0N4CHFI045123>