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

On Tue, Sep 27, 2005 at 03:55:46PM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> unless anyone objects, i'll remove the following VOPs.
> ie. make them filesystem internal.
>=20
> 	VOP_BLKATOFF
> 	VOP_VALLOC
> 	VOP_REALLOCBLKS

Nothing actually uses that one (VOP_REALLOCBLKS) in the trees I have. So I
think it can just go away.

> 	VOP_VFREE
> 	VOP_TRUNCATE
> 	VOP_UPDATE
>=20
> afaik there is no point to export them.

VOP_UPDATE is used by genfs_fsync, which is in turn used by ntfs, msdosfs,=
=20
and ext2fs.

All of the operations (except VOP_REALLOCBLKS) are used a lot by ufs, for
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 system
in addition to the VOP system. So I think it'd be better to just leave
these operations as VOPs.

Also, a number of other file systems use these VOPs internally, so they=20
seem to be convenient operations. :-)

I however agree with what I think is the underlying point, that these
operations are different from the other VOP operations. That they are
intended to be called from within the file system exclusively, whereas all=
=20
the other ops are intended to be called from outside the file system.

So how about this idea: we remove these operations from the exposed set of=
=20
operations, but we keep them around in the VOP interface. File systems can=
=20
still define them, and file system code can still use them. We perhaps can=
=20
rename them VOP_INT_XXX, to be clear.

While I'm not sure how to do it, I think it would also be appropriate if=20
we got kern/vnode_if.sh to generate kern/vnode_if_int.c and=20
sys/vnode_if_int.h, and for file systems that use these operations to have=
=20
to include sys/vnode_if_int.h themselves.

Further, I think it would be fine for each file system to define its own=20
locking on these calls, as it (or its family of file systems for ufs) will=
=20
be able to follow whatever scheme it needs. At the vnode_if_int.src level,=
=20
these operations would be defined to follow the locking defined for/by the=
=20
file system.

In summary, I object to getting rid of most of these operations, as I=20
think that a number of file systems find the VOP interface to be a=20
convenient way to internally dispatch these operation. I however have NO=20
objection to hiding them and making it so that ONLY file system specific=20
code is able to use them.

Take care,

Bill

P.S. One of my main resons for not minding what we do is that I can't
think of a better way to handle the indirection we will need than just
using the VOP system. If someone comes up with one, I'd be happy to
consider it.

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

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

iD8DBQFDOXy9Wz+3JHUci9cRAi6mAKCXPpfsPb/PqhzgGaews0Fg/cQvhgCdEePr
sVnvWJ1iOc9J7d34dy3eer4=
=TfJJ
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--