Thus spake Juergen Hannken-Illjes ("JH> ") sometime Today...

JH> VOP_STRATEGY is no real VOP because it is missing a vnode as a first
JH> argument. I propose to convert  VOP_STRATEGY(bp)  to two functions
JH> VOP_STRATEGY(vp, bp)  and  DEV_STRATEGY(bp)  as follows:
JH>
JH>  VOP_STRATEGY(vp, bp) will run the strategy routine for the  vp  arg
JH>  and the conversion is like  VOP_STRATEGY(bp) -> VOP_STRATEGY(bp->b_vp, bp).

Given that example, that makes no sense whatsoever.  Why send bp->b_vp
when you can extract b_vp from bp?

On the other hand, if you are not always sending bp->b_vp along with bp,
it makes much sense.

JH>  DEV_STRATEGY(bp) is used for block-to-block device situations and calls
JH>  the d_strategy() routine from device bp->b_dev.
JH>
JH> With these changes applied, VOP_STRATEGY is no longer a special-case VOP
JH> and spec_strategy() always gets the vnode of the block device to call.
JH> This will make it more easy to put copy-on-write data into the specinfo
JH> of the block device.
JH>
JH> Comments?

Is this merely a matter of semantics, then?  I suppose consistency is
a laudable goal and will probably simplify things down the road.  It just
never made sense to send an object and a subordinate of that same object
as two separate parameters, since you can extract the sub from the object.

				--*greywolf;
--
22 Ways to Get Yourself Killed While Watching 'The Lord Of The Rings':

#10: When Denethor lights the fire, shout "Barbecue!"