Subject: Re: removing VOPs
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/03/2005 12:02:08
Content-Type: text/plain; charset=us-ascii
On Fri, Sep 30, 2005 at 11:07:09AM +0900, YAMAMOTO Takashi wrote:
> > 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.
> > 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.
> > 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----