Subject: Re: removing VOPs
To: YAMAMOTO Takashi <>
From: Bill Studenmund <>
List: tech-kern
Date: 10/03/2005 12:02:08
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 30, 2005 at 11:07:09AM +0900, YAMAMOTO Takashi wrote:
> >=20
> > 1) See below. The need to change sys/ and kern/ is an artifact of our V=
> > implementation infrastructure. The fact that our VOP system could be us=
> > to add an operation the original kernel didn't know anything about was=
> > considered a plus. And I still think it is.
> >=20
> > The only thing that would need changing would be an interface to add ne=
> > operations in addition to those in vfs_op_descs. It'd be a touch tricky=
> > we would need to add a slot in all the existing op tables for the new o=
> > but it could be done.
> i don't think it's worth to do, given locking overhead and complexity.

What locking overhead? Also, while I see adding a new op would be a bit=20
irritating to code, I don't think it's that complex. Note: I am of course=
assuming the case of only adding new operations and never removing them,=20
even if the only fs that implements them gets unloaded from a kernel.

I'll be honest that I am not about to race out and implement this, but I'd=
like to better understand your concerns; I could be missing something. :-)

> > 2) I agree that an operation that would never be used in another fs sho=
> > not be added to sys/ and kern/. But if two or three file systems or file
> > system families happen to internally do the same thing and need the same
> > ops, it strikes me as reasonable to include convenience definitions tha=
> > they can all share. It's a judgement call.
> what's wrong with GOPs and ufs_ops in this respect?

In that respect, not much. They are the flip-side of teh judgement call.

> > > i can see your point.  however, i have a different opinion.
> >=20
> > Well, you've listened to me and I've listened to you. We will just=20
> > disagree then and I'll look forward to seeing your proposed patch.
> i'll create a branch so you will be able to see the changes before
> they hit the trunk.

Ok, if that's easier for you. I thought a diff would be more than=20

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)