Date: Wed, 22 Jan 2003 18:23:07 -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: <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> In-Reply-To: <200301222249.h0MMn9e5016697@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 22 Jan 2003 14:49:09 -0800 (PST), Matthew Dillon <dillon@apollo.backplane.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301222323.h0MNN7co043532>