Date: Mon, 13 Jan 2003 22:11:27 -0600 From: "Alan L. Cox" <alc@imimic.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: Virtual memory question Message-ID: <3E238DEF.14DFA7E1@imimic.com> References: <20030114002831.1C8C12A89E@canning.wemm.org> <3E2381F8.85BB90A0@imimic.com> <200301140339.h0E3dVQa073160@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E238DEF.14DFA7E1>