From owner-freebsd-arch Wed Jan 22 20:31:49 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 1022E37B405 for ; Wed, 22 Jan 2003 20:31:48 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB1D243ED8 for ; Wed, 22 Jan 2003 20:31:46 -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 h0N4Vibs045187 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 23:31:44 -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 h0N4ViJ6045184; Wed, 22 Jan 2003 23:31:44 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 23:31:44 -0500 (EST) From: Garrett Wollman Message-Id: <200301230431.h0N4ViJ6045184@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) 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> 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: > (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