Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Mar 2002 12:13:10 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Brian F. Feldman" <green@FreeBSD.org>
Cc:        arch@FreeBSD.org
Subject:   Re: vnode::v_op bugfix / PERFORCE change 8574 for review (fwd)
Message-ID:  <3CA37956.2F92476B@mindspring.com>
References:  <200203281929.g2SJTBW04780@green.bikeshed.org>

next in thread | previous in thread | raw e-mail | index | archive | help
"Brian F. Feldman" wrote:
> 
> This seems to fix -CURRENT after the last round of bugs that UMA evidenced.
> Does anyone have objections to modifying this behavior of VFS?  I have a
> copy of the patch to get between the two up at:
>         http://green.bikeshed.org/~green/v_op-indirection.patch

The vfs_default.c code comes from the universe where Spock has
a beard.


I know I suggested the change made by this patch, but it's only
actually a workaround to a problem that wouldn't exist, if it
weren't for vfs_default.c.

And it's a bad workaround, at that.  8-(.

It was really meant as a single-instance workaround for the NTFS
maintainer to be able to do the load/unload during developement
work on the module, pending real fixes to the VFS code to bring it
back in line with the design documentation from UCLA/FICUS.

The only place it bites you is adding new VOPs in a loadable
module, which should not bite you in the first place, and
wouldn't, if the default for everything was "unimplemented",
like it was designed to be, instead of having defaults that
do something, like there are now.

As it is, it's impossible to proxy descriptors across an interface
that doesn't know about all the possible descriptors.  This is
just plain wrong.

Unless you can add default implementations for default_vops
when you add a new VOP, this whole mess doesn't make sense in
any universe.  Even then, it makes little sense: you have to
look at it from the right perverse angle, like the joke about
the tailor:   "Oh, that poor man!"  "Yes, but what a wonderful
suit!".

-- Terry

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?3CA37956.2F92476B>