Date: Wed, 14 Feb 2001 14:37:53 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Adrian Chadd <adrian@FreeBSD.ORG> Cc: Dag-Erling Smorgrav <des@ofug.org>, Jake Burkholder <jburkholder0829@home.com>, freebsd-current@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ... Message-ID: <Pine.NEB.3.96L.1010214142925.21766B-100000@fledge.watson.org> In-Reply-To: <20010214171930.A1587@roaming.cacheboy.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Feb 2001, Adrian Chadd wrote:
> *sigh* now, if we had per-file open vnode[1] support, I could quite
> happily solve this by fixing procfs, but people view procfs as bad for
> some reason.
>
> [1] Ignore my vagueness in terms here - the general request is to have
> some form of state mapped back to an open file from the VNOPS. This
> way at VOP_OPEN() I can populate the file data with some proc info,
> and then VOP_READ/VOP_WRITE just read from this, rather than the
> evilness (and non-atomic) way they work right now[2].
I had patches that did a lot of this at one point, although I'd object to
proc info, what you really want is struct file info (that is,
per-open-file information). The way I handled it was to add an additional
argument to the relevant VOP_ calls that was a cookie reference. So it
became something on the order of (approximate):
vop_open {
IN struct vnode *vp;
IN int mode;
IN struct ucred *cred;
IN struct proc *p;
INOUT void **cookie;
};
...
vop_read {
IN struct vnode *vp;
INOUT struct uio *uio;
IN int ioflag;
IN struct ucred *cred;
IN void *cookie;
};
...
And so on. If VOP_OPEN() was called with a non-null (void *), the cookie
would be filled in by the vnode owner. Later operations could have the
cookie passed in again for stateful operation, or NULL for stateless.
struct file had a cookie pointer added to it so that struct file-based
access became stateful. When stacking file systems, state mapping could
optionally be performed to allow sessions to propagate up and down the
stacked layers as the layer implementers saw fit (either by passing
through the cookie directly, or storing a cookie pointer in their own
cookie).
If you have it be per-process state, that breaks (a) multiple-opening
where you want to get different sessions and (b) retaining the same
session when using multiple processes (especially when using linux-style
threading). I didn't play with propagating this down through the device
layer, but if you wanted to do that you'd have to clean up the apropriate
mechanisms to make sure that all open's were symmetric with closes on
vnodes and on devices through the vnode layer.
There are probably problems with this design -- I played with it some, but
it lagged behind -CURRENT substantially after a while, and I don't think I
have that dev tree anymore. This design does allow the file system to
define statefulness in any form it would like to, storing whatever
information the file sytem implementation thinks is useful. It could
easily be a pointer to a struct of some sort, an integer, a pid, ..
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010214142925.21766B-100000>