--7ZAtKRhVyVSsbBD2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 28, 2005 at 07:14:31AM +0900, YAMAMOTO Takashi wrote:
>=20
> > All of the operations (except VOP_REALLOCBLKS) are used a lot by ufs, f=
or
> > ffs, lfs, and ext2fs vnodes. The kind of indirection mapping that ufs
> > needs is exactly that which the VOP system provides. So if we make them
> > fs-private, I think we will have to end up with another indirection sys=
tem
> > in addition to the VOP system. So I think it'd be better to just leave
> > these operations as VOPs.
>=20
> sounds nonsense to me.
> if you need another indirection, have another indirection.
> it isn't a good excuse to abuse VOPs.

Since when are VOPs so holy that their use in a manner which predated=20
NetBSD by years is an abuse? :-)

Also, we have VOP indirection. We evidently now have GOP (which I was=20
unaware of). UFS will need some form of comparable indirection goign with=
=20
what you suggest. We will then end up with three indirection methods that=
=20
are mostly alike yet different. If we are talking about cleanliness, how=20
is it cleaner to do almost the same thing three different ways?

We're doing C++ in C. Why do it three times? :-)

> > Also, a number of other file systems use these VOPs internally, so they=
=20
> > seem to be convenient operations. :-)
>=20
> i guess that they were just copied from ufs. :-)

Could be.

> > Further, I think it would be fine for each file system to define its ow=
n=20
> > locking on these calls, as it (or its family of file systems for ufs) w=
ill=20
> > be able to follow whatever scheme it needs. At the vnode_if_int.src lev=
el,=20
> > these operations would be defined to follow the locking defined for/by =
the=20
> > file system.
>=20
> having such filesystem internal things in sys/ or kern/ is a bad idea.

Why?

They aren't getting in the way of any real fixes or feature additions (if=
=20
they were, I would be fully supporting this change). FSs that don't need=20
them ignore them.

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 have=
=20
to be defined in vfs_op_descs.

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 and
implement them as they wish.

The VOP layer really is the right level to have this (VALLOC, VFREE, etc.)=
=20
abstraction. We want to make ffs, lfs, and ext2fs vnodes to be subclasses=
=20
of a ufs vnode, and VOP is the place for it.

I agree that things outside of ufs don't need to know about them, and=20
actually DO need to be told to keep out.


> besides, i'd like to make most of VOP_LOCK style locking
> filesystem internal, eventually.

Uhm, I was saying that we start here. :-) And I agree with you on this=20
point. :-)

Take care,

Bill

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

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

iD8DBQFDOenyWz+3JHUci9cRAtWtAKCU5Qvyih4MM116wLiUS+9bIfi/vQCgg5gw
a270b0mKQlYIMpOc8eW4JT8=
=tgY9
-----END PGP SIGNATURE-----

--7ZAtKRhVyVSsbBD2--