From owner-freebsd-arch Mon Jan 13 20:11:34 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 01CAD37B405 for ; Mon, 13 Jan 2003 20:11:33 -0800 (PST) Received: from eumenes.hosting.swbell.net (eumenes.hosting.swbell.net [216.100.98.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25EB643F3F for ; Mon, 13 Jan 2003 20:11:32 -0800 (PST) (envelope-from alc@imimic.com) Received: from imimic.com (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) by eumenes.hosting.swbell.net id XAA19818; Mon, 13 Jan 2003 23:11:28 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <3E238DEF.14DFA7E1@imimic.com> Date: Mon, 13 Jan 2003 22:11:27 -0600 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: Virtual memory question References: <20030114002831.1C8C12A89E@canning.wemm.org> <3E2381F8.85BB90A0@imimic.com> <200301140339.h0E3dVQa073160@apollo.backplane.com> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit 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 Matthew Dillon wrote: > ... > 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. It's probably better to look at the actual specification rather than our manual page: http://www.opengroup.org/onlinepubs/7908799/xsh/shm_open.html. I think it better describes the things that are left unspecified (and allow a great deal of flexibility in the implementation). As far as the name space goes, I still tend to think that an in-kernel hash table is the way to go. If the "path" begins with a '/', it's the entire key. Otherwise, you add something identifying the process to the key. I'm happy with the NULL path as an extension to this interface. > (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()? I think the size is implied by the mmap()ing. A second, larger mmap()ing would have to grow the object. An object should never shrink. Regards, Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message