From owner-freebsd-arch Wed Jan 22 20:12:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D36237B401 for ; Wed, 22 Jan 2003 20:12:24 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89B9F43ED8 for ; Wed, 22 Jan 2003 20:12:23 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0N4CHbs045126 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 23:12:17 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0N4CHFI045123; Wed, 22 Jan 2003 23:12:17 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 23:12:17 -0500 (EST) From: Garrett Wollman Message-Id: <200301230412.h0N4CHFI045123@khavrinen.lcs.mit.edu> To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <20030123033918.DE9372A7EA@canning.wemm.org> References: <200301230313.h0N3DmPP044886@khavrinen.lcs.mit.edu> <20030123033918.DE9372A7EA@canning.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.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