From owner-freebsd-arch Wed Jan 22 14:16:39 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5389937B401 for ; Wed, 22 Jan 2003 14:16:37 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEA2043F1E for ; Wed, 22 Jan 2003 14:16:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0MMGa0i010111; Wed, 22 Jan 2003 14:16:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0MMGZMD010110; Wed, 22 Jan 2003 14:16:35 -0800 (PST) Date: Wed, 22 Jan 2003 14:16:35 -0800 (PST) From: Matthew Dillon Message-Id: <200301222216.h0MMGZMD010110@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.com> <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 : :< 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message