From owner-freebsd-arch Wed Jan 22 15:23:13 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 1998837B405 for ; Wed, 22 Jan 2003 15:23:11 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E3943F43 for ; Wed, 22 Jan 2003 15:23:09 -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 h0MNN7bs043535 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 18:23:08 -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 h0MNN7co043532; Wed, 22 Jan 2003 18:23:07 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 18:23:07 -0500 (EST) From: Garrett Wollman Message-Id: <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301222249.h0MMn9e5016697@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@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: > Moving shm_open() to kernel space? That's a pretty tall order. I > don't think anyone has proposed that until now. It was always my expectation that this would happen at some point. > shm_open() in its full glory must manage both namespace private > and namespace-filespace operations. Huh? This doesn't make any sense. > I would argue that namespace private operations are far better handled > in userspace then kernelspace (why waste kernel memory managing > private namespaces?). Private namespaces are bad and unnecessary. We already have anonymous shared memory; I don't see any need for ``semi-anonymous'' shared memory. The garbage-collection problem is already bad enough. > I would say that we would almost certainly want > to keep shm_open() in userspace and add a system call (aka getmemfd()) > that can eventually be used to support shm_open() behind the scenes. You haven't provided any justification that I've seen for introducing a new interface when the one we've got can already do that. > Additionally, namespace-filespace operations are far better handled with Undefined external reference. I've never heard the term ``namespace-filespace'' before and do not understand the distinction you are trying to make. > To do that requires a two-stage process of which my current proposed > patch is only stage-1, since we have no current ability to call > ftruncate() on a descriptor, only a vnode. Trivial under my proposal... here's the conceptual patch: Index: vfs_syscalls.c =================================================================== RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.297 diff -u -r1.297 vfs_syscalls.c --- vfs_syscalls.c 27 Oct 2002 23:23:51 -0000 1.297 +++ vfs_syscalls.c 22 Jan 2003 23:19:31 -0000 @@ -2598,6 +2598,16 @@ fdrop(fp, td); return (EINVAL); } + if (fp->f_type == DTYPE_SHM) { + /* + * Don't touch the rendezvous file when changing the size + * on an SHM descriptor. There may be a need for a MAC + * check here or in shm_setsize(). + */ + error = shm_setsize(fp->f_ipcobj, uap->length); + goto out; + } + vp = (struct vnode *)fp->f_data; if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0) { fdrop(fp, td); @@ -2619,6 +2629,7 @@ } VOP_UNLOCK(vp, 0, td); vn_finished_write(mp); +out: fdrop(fp, td); return (error); } @@ -3414,7 +3425,9 @@ if ((u_int)fd >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[fd]) == NULL) error = EBADF; - else if (fp->f_type != DTYPE_VNODE && fp->f_type != DTYPE_FIFO) { + else if (fp->f_type != DTYPE_VNODE && + fp->f_type != DTYPE_FIFO && + fp->f_type != DTYPE_SHM) { fp = NULL; error = EINVAL; } else { This is one way to do it, assuming that we want the vnode layer to be completely oblivious to the shared-memory implementation (which I think is your intent and an approach I agree with). -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message