From owner-freebsd-arch Wed Jan 22 15: 1:59 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 DF70D37B401 for ; Wed, 22 Jan 2003 15:01:57 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3323A43EB2 for ; Wed, 22 Jan 2003 15:01:57 -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 h0MN1obs043397 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 18:01:50 -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 h0MN1nHg043396; Wed, 22 Jan 2003 18:01:49 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 18:01:49 -0500 (EST) From: Garrett Wollman Message-Id: <200301222301.h0MN1nHg043396@khavrinen.lcs.mit.edu> To: jroberson@chesapeake.net Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <20030122173229.D46974-100000@mail.chesapeake.net> References: <200301222144.h0MLifiC009829@apollo.backplane.com> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.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 -----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