Date: Wed, 22 Jan 2003 17:10:00 -0500 (EST) From: Garrett Wollman <wollman@lcs.mit.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> In-Reply-To: <200301222144.h0MLifiC009829@apollo.backplane.com> References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 22 Jan 2003 13:44:41 -0800 (PST), Matthew Dillon <dillon@apollo.backplane.com> said: > You guys are talking apples and oranges here. shm_open() is a libc > call, not a system call. Erm, no. It's an *interface*. Whether its implementation in the C library is complete or merely a syscall stub is irrelevant. > be compatible. e.g. you can call ftruncate() on an shm_open() > descriptor (because it is essentially just a file descriptor), but you > cannot call ftruncate() on a getmemfd() descriptor. Why not? We already have a round wheel, I see no need for additional square ones. > The primary problem with using shm_open() in its current implementation > is the fact that the anonymous memory associated with the descriptor > is file-backed when what we really want is swap-backed anonymous memory. Only in the current implementation. Nothing in the definition of shm_open() requires it to access the filesystem at all, although since a shared memory object has many attributes -- such as naming and access-control semantics -- that the filesystem already models well, it is probably preferable to continue to use it to manage those attributes. A simple implementation would add an additional field to `struct file'; perhaps call it `f_ipcobject'. Then you have the following model of operations: - open() operates on the file itself, with no special semantics - shm_open() performs all of the operations of open(), but also looks up the abstract name of the file[1] and creates or attaches an IPC object to the descriptor and changes the type to DTYPE_SHM. - ftruncate() when performed on a DTYPE_SHM descriptor changes the size of the IPC object rather than the rendezvous file. - shm_unlink() performs all of the operations of unlink(), but also looks up the abstract name of the file and marks the related IPC object, if any exists, for removal. - fstat() gets the IPC object's size and sets the SHM bit in the status buffer after getting other attributes from the vnode layer. - all other file operations pass through to the usual vnode operations. -GAWollman [1] E.g., a vnode pointer value or an NFS-style file handle. If the former is used, the IPC object would obviously have to keep a reference to the vnode so that it couldn't be recycled. 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?200301222210.h0MMA0gB042902>