hi,

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

genfs belongs to filesystem internal.
if it's needed (i don't think so), use GOP.

> 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.

sounds nonsense to me.
if you need another indirection, have another indirection.
it isn't a good excuse to abuse VOPs.

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

i guess that they were just copied from ufs. :-)

> 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 
> 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 
> operations, but we keep them around in the VOP interface. File systems can 
> still define them, and file system code can still use them. We perhaps can 
> 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 
> we got kern/vnode_if.sh to generate kern/vnode_if_int.c and 
> sys/vnode_if_int.h, and for file systems that use these operations to have 
> to include sys/vnode_if_int.h themselves.
> 
> Further, I think it would be fine for each file system to define its own 
> locking on these calls, as it (or its family of file systems for ufs) will 
> be able to follow whatever scheme it needs. At the vnode_if_int.src level, 
> these operations would be defined to follow the locking defined for/by the 
> file system.

having such filesystem internal things in sys/ or kern/ is a bad idea.

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

YAMAMOTO Takashi