From owner-freebsd-arch Mon Jan 13 19:39:33 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 2979B37B407 for ; Mon, 13 Jan 2003 19:39:32 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C381143ED8 for ; Mon, 13 Jan 2003 19:39:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0E3dV0i073161; Mon, 13 Jan 2003 19:39:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0E3dVQa073160; Mon, 13 Jan 2003 19:39:31 -0800 (PST) Date: Mon, 13 Jan 2003 19:39:31 -0800 (PST) From: Matthew Dillon Message-Id: <200301140339.h0E3dVQa073160@apollo.backplane.com> To: "Alan L. Cox" Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: Virtual memory question References: <20030114002831.1C8C12A89E@canning.wemm.org> <3E2381F8.85BB90A0@imimic.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 Well, if we need kernel support anyway to get out from under the file-backed issue (this is what Peter is trying to avoid), there would be a system call anway and Peter could just use it. So he gets his direct call for free even though we would also keep the shm_open() interface and implement it or partially implement it with the new system call. I see two major deficiencies with shm_open(). (1) There is no way to say "give me a new memory area". i.e. passing a path of NULL is not legal. On the otherhand, after reading the manual page it is clear that you *CAN* give shm_open() a non-/ name and libc could manage the namespace/descriptor association internally. Still, if you want an unassociated object we should allow NULL. (2) I don't see how/where one specifies the size of the memory object in shm_open(). Does this mean we have to implement ftruncate()? -Matt Matthew Dillon :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. : :Regards, :Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message