hi,

> > do you mean that you want to abstract any use of
> > function pointers so that they can share the code?
> > sounds impractical to me.
> 
> No, not any use of function pointers. But if the abstraction layers are 
> each cutting the same object at the same place, why duplicate?

because it's acutally not the same place.

> > > > 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?
> 
> 1) See below. The need to change sys/ and kern/ is an artifact of our VOP 
> implementation infrastructure. The fact that our VOP system could be used 
> to add an operation the original kernel didn't know anything about was 
> considered a plus. And I still think it is.
> 
> The only thing that would need changing would be an interface to add new 
> operations in addition to those in vfs_op_descs. It'd be a touch tricky as 
> we would need to add a slot in all the existing op tables for the new one, 
> but it could be done.

i don't think it's worth to do, given locking overhead and complexity.

> 2) I agree that an operation that would never be used in another fs should
> not be added to sys/ and kern/. But if two or three file systems or file
> system families happen to internally do the same thing and need the same
> ops, it strikes me as reasonable to include convenience definitions that 
> they can all share. It's a judgement call.

what's wrong with GOPs and ufs_ops in this respect?

> > i can see your point.  however, i have a different opinion.
> 
> Well, you've listened to me and I've listened to you. We will just 
> disagree then and I'll look forward to seeing your proposed patch.

i'll create a branch so you will be able to see the changes before
they hit the trunk.

YAMAMOTO Takashi