--IiVenqGWf+H9Y6IX
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=
OP=20
> > implementation infrastructure. The fact that our VOP system could be us=
ed=20
> > to add an operation the original kernel didn't know anything about was=
=20
> > considered a plus. And I still think it is.
> >=20
> > The only thing that would need changing would be an interface to add ne=
w=20
> > operations in addition to those in vfs_op_descs. It'd be a touch tricky=
 as=20
> > we would need to add a slot in all the existing op tables for the new o=
ne,=20
> > but it could be done.
>=20
> 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=
=20
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=
=20
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=
uld
> > 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=
t=20
> > they can all share. It's a judgement call.
>=20
> 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.
>=20
> 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
sufficient.

Take care,

Bill

--IiVenqGWf+H9Y6IX
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDQYAwWz+3JHUci9cRAsVDAJwNJD50M1+l3dOiixX3c1yXi+HbTwCaAv0v
sCPoIUz1maLiUmRZ7m/AEFs=
=BeUy
-----END PGP SIGNATURE-----

--IiVenqGWf+H9Y6IX--