On Wed, 18 Apr 2001, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> > If this will get rid of or clean up the specfs garbage, then I'm all
> > for it. I would love to see a 'clean' fileops based device interface.
>
> specfs, aliased vnodes, you name it...
>
> I think the aliased vnodes is the single most strong argument of them
> all for doing this...
I think that this can be (and already is) solved in the other
way. Here is how I done it on my test system (quoted from the mail to
Bruce Evans):
--quote-start--
I'm working on this problem too, and these vop_lock/unlock in the
spec_open/read/write vnops cause a real pain. Using a generic vnode
stacking/layering mechanism (diffs will be published soon) I've
reorganized the way how device vnodes are handled. Each device gets its
own vnode of type VT_SPEC which is belongs to a hidden specfs mount. When
any real filesystem tries to lookup vnode for a specific device via
addaliasu(), addalias() just stacks filesystem vnode over specfs vnode:
fs1/vnode1 fs1/vnode8 fs2/vnode1
| | |
+-------+-----------------------+
|
V
specfs vnode
Specfs vnode also can be used directly as root vnode for any
mounted filesystem. Obviously, there is no need in the device aliases
because device can be controlled only via single vnode. v_rdev field is
also goes away from vnode structure and vn_todev() is the right way to get
a pointer to underlying device.
But there is a real problem with a locking/unlocking used by
specfs. Eg, if specfs vnode's lock used as lock for an entire layer tree,
then things will be totally broken because blocked spec_read() operation
may unlock a different vnode which should be locked, and even more
problems caused that the read lock is shared... Use of separate lock for
each vnode partially solves the problem, but not completely emulates the
old behavior for exclusive lock on open operation. For example if we call
open(vn1) and it block, the second open(vn1) will stuck waiting for lock
on vn1, while open(vn8) will work just fine.
This problem is common for stacked filesystems and many papers
avoid talking about it. The "right" solution is to have a "call stack", so
an unlock operation can unlock only a single chain of the above vnodes,
but I'm don't see the simple way to implement it for stacks containing
more than two layers :(
--quote-end--
Now, regarding to the new file operations structure: it is pretty
obvious that most of the operations will resemble vnode operations.
However, it is a misdesign of VFS to not allow a filesystem to track a
per-file descriptor tracking for at least OPEN/CLOSE operations. It is
also a pretty obvious that file operations (FOP) are just a layer above
VOP operations.
So, why not to do things right and add capability to the existing
VFS to handle a per-file operations properly ? Of course, this will
require more brain work, but results will be definitely better.
Lets back to vnode/vm/file/devices: I think it is a mistake to rip
out vnodes from devices. But I'm agree that vnode structure is too fat to
be used in the more general way. If it is possible to cleanup it, then we
can easily build any hierarchies we want:
file1 file2 file3
| | |
+-------+ |
| |
vnode1 vnode2
| |
+---------------+
|
device1
--
Boris Popov
http://www.butya.kz/~bp/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
