--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 29, 2005 at 08:53:19AM +0900, YAMAMOTO Takashi wrote:
> > Since when are VOPs so holy that their use in a manner which predated=
=20
> > NetBSD by years is an abuse? :-)
>=20
> well, now? :-)

Then you are now adding that "holiness." Which is ok, except your
arguement came across as having the "new holiness" (VOP interface is for
external uses only) as a pre-existing given. It obviously isn't, as at
least Berkeley felt the existing mixing was fine. :-)

If you want to change the definition, fine. If you want to make the code=20
match the new definition at the same time, fine. Just don't use the new=20
definition as a pre-existing reason to change the code. That's circular=20
reasoning. :-)

> > We're doing C++ in C. Why do it three times? :-)
>=20
> we are not doing C++.

True, but we are doing objects.

> do you mean that you want to abstract any use of
> function pointers so that they can share the code?
> sounds impractical to me.

No, not any use of function pointers. But if the abstraction layers are=20
each cutting the same object at the same place, why duplicate?

> > > having such filesystem internal things in sys/ or kern/ is a bad idea.
> >=20
> > Why?
>=20
> do you seriously think that it's good to modifing sys/ or kern/ whenever
> you introduce a VOP which is specific to your own filesystem?

1) See below. The need to change sys/ and kern/ is an artifact of our VOP=
=20
implementation infrastructure. The fact that our VOP system could be used=
=20
to add an operation the original kernel didn't know anything about was=20
considered a plus. And I still think it is.

The only thing that would need changing would be an interface to add new=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 one,=
=20
but it could be done.

2) I agree that an operation that would never be used in another fs should
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 that=20
they can all share. It's a judgement call.

> > To be honest, the bug really isn't that we have these ops in sys/ or=20
> > kern/, but that our VOP interface can't be extended; all of the VOPs ha=
ve=20
> > to be defined in vfs_op_descs.
> >=20
> > If we weakened that, and let file systems add their own ops, then ufs
> > could add its own ops and then ffs, lfs, ufs, and ext2fs can use them a=
nd
> > implement them as they wish.
> >=20
> > The VOP layer really is the right level to have this (VALLOC, VFREE, et=
c.)=20
> > abstraction. We want to make ffs, lfs, and ext2fs vnodes to be subclass=
es=20
> > of a ufs vnode, and VOP is the place for it.
>=20
> 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.

Take care,

Bill

--BOKacYhQ+x31HxR3
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDPCzoWz+3JHUci9cRApEnAJ9sdx4Im1ZQxR8IoqhAHCvwrs0eFQCgjdsN
7n3EbMVkP4r+JKr1R8prj48=
=LMzR
-----END PGP SIGNATURE-----

--BOKacYhQ+x31HxR3--