Date: Tue, 21 Jan 2003 17:53:31 -0500 (EST) From: Garrett Wollman <wollman@lcs.mit.edu> To: peter@wemm.org Cc: arch@FreeBSD.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301212253.h0LMrVhA018739@khavrinen.lcs.mit.edu> In-Reply-To: <20030121185208.A82EB2A7EA@canning.wemm.org> References: <Pine.NEB.3.96L.1030121132828.11405D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20030121185208.A82EB2A7EA@canning.wemm.org>, Peter Wemm quoted Robert Watson who said: >> (3) DTYPE_MEMFD >> Handle the implementation using a special file descriptor type >> creating using a special creation primitive (similar to kqueue, >> pipe, etc). >(3) is cleaner but requires a more code to add the DTYPE_xxxFD stuff and >affects more places in the kernel where we switch() on fd types. I >personally prefer (3) (3) is certainly closer to what the designers of the POSIX IPC interface were thinking. It has the significant benefit of not creating any additional kernel namespaces (which I think we would all agree was one of the worst mistakes in the SVR3 IPC model). Given (3), the implementation of shm_open() and shm_unlink() should move into the kernel, and those functions (rather than a special-purpose system call) should be used to provide this interface. shm_open() effectively looks like this: - examine first byte of path parameter - if c == '/' return open(...) - copy in path - use path to find/create shm object - create file descriptor a la open() with DTYPE_SHM We will need to find a spare bit in struct stat so that fstat() on one of these descriptors can indicate to S_TYPEISSHM() what it is. -GAWollman 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?200301212253.h0LMrVhA018739>