From owner-freebsd-arch Mon Jan 13 20:14:15 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 50B0137B401 for ; Mon, 13 Jan 2003 20:14:13 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BF9043F13 for ; Mon, 13 Jan 2003 20:14:13 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id DDFC32A89E; Mon, 13 Jan 2003 20:14:07 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Alan L. Cox" Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: Virtual memory question In-Reply-To: <3E2381F8.85BB90A0@imimic.com> Date: Mon, 13 Jan 2003 20:14:07 -0800 From: Peter Wemm Message-Id: <20030114041407.DDFC32A89E@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 "Alan L. Cox" wrote: > Peter Wemm wrote: > > > > "Alan L. Cox" wrote: > > > Matthew Dillon wrote: > > > > ... > > > > How about something like: > > > > > > > > getmemfd(). > > > > > > > > > > Roughly speaking, this is shm_open(3), which we currently implement > > > using files. > > > > .. which is expressly what I wanted to avoid. > > > > Your response is ambiguous. :-) It doesn't say whether you want to > avoid shm_open(3) the interface or rather FreeBSD's implementation of > it. Personally, I'm all for changing the implementation in the way Matt > describes, but I haven't yet heard a rationale for a new interface. > Specifically, the interface proposed thus far could be emulated by > > fd = shm_open("unique name", ...); > shm_unlink("unique name"); > > The spec also seems to makes the creation of unique names easy: "If name > does not begin with the slash character, the effect is > implementation-dependent." So, a per-process name space is allowed for > names not beginning with slash. > > Furthermore, the only operations that I know of on a "path" are > shm_open() and shm_unlink(), and my reading of those was that a hash > table keyed on the "path" was a legal implementation. > > In summary, a new implementation would be good, but I haven't seen the > rationale for a new interface, especially given that shm_open(3) is an > existing standard. Sorry about the ambiguity. My problem with the shm_*() calls is that the API is pretty heavily tied to the file system. If there is a way to avoid that, then fine. It looks like one needs to ftruncate() it to resize a shm_open() object. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message