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

well, now? :-)

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

we are not doing C++.

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

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

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?

> To be honest, the bug really isn't that we have these ops in sys/ or 
> kern/, but that our VOP interface can't be extended; all of the VOPs have 
> 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.) 
> abstraction. We want to make ffs, lfs, and ext2fs vnodes to be subclasses 
> of a ufs vnode, and VOP is the place for it.

i can see your point.  however, i have a different opinion.
GOPs and "ufs ops" don't need complexity which VOP has.
plain function pointers are just fine.
(i doubt if VOPs really need this complexity, but it's another topic.)

YAMAMOTO Takashi