From owner-cvs-all Wed Feb 14 12: 9:29 2001 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id D2F1137B4EC; Wed, 14 Feb 2001 12:09:18 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1EJbrh25210; Wed, 14 Feb 2001 14:37:53 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Feb 2001 14:37:53 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Adrian Chadd Cc: Dag-Erling Smorgrav , Jake Burkholder , 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 ... In-Reply-To: <20010214171930.A1587@roaming.cacheboy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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