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