Date: Wed, 22 Jan 2003 14:16:35 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301222216.h0MMGZMD010110@apollo.backplane.com> References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.com> <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett, I fail to see what you are argument is here. Are you arguing for the addition of a system call or against? shm_open() is irrelevant to the discussion, it is a libc function which has no capability whatsoever of implementing the features we need for a shared-memory descriptor, which have already been outlined in prior emails. Even if we were to add a more complete function vector to the struct file, it still would not in any way implement the shared memory features we need on a standard file. What I was saying was that a struct file function vector would allow a special memory descriptor to become compatible with the shm_open() API. But you still need the new system call to get that special memory descriptor... adding a function vector does not in any way allow you to avoid adding the system call. Apples and Oranges. -Matt : :<<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. : Matthew Dillon <dillon@backplane.com> 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?200301222216.h0MMGZMD010110>