Subject: Re: removing VOPs
To: None <wrstuden@netbsd.org>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 09/28/2005 07:14:31
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