From owner-freebsd-arch Wed Jan 22 14:10: 6 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 8823D37B401 for ; Wed, 22 Jan 2003 14:10:04 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF0F143F13 for ; Wed, 22 Jan 2003 14:10:03 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0MMA1bs042905 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 17:10:01 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0MMA0gB042902; Wed, 22 Jan 2003 17:10:00 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 17:10:00 -0500 (EST) From: Garrett Wollman Message-Id: <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) 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> 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 < 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