Subject: Re: Make VOP_STRATEGY a real VOP
To: Juergen Hannken-Illjes <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 01/19/2004 13:42:34
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> 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> 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.
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.
22 Ways to Get Yourself Killed While Watching 'The Lord Of The Rings':
#10: When Denethor lights the fire, shout "Barbecue!"