Re: [ANNOUNCE] Status of unlocked_qcmds=1 operation for .37

[Jeff Garzik <jeff@garzik.org>]

On 10/27/2010 02:06 PM, Nicholas A. Bellinger wrote:
> On Wed, 2010-10-27 at 09:27 -0500, James Bottomley wrote:
>> On Wed, 2010-10-27 at 09:53 +0200, Andi Kleen wrote:
>>>> This sounds like a pretty reasonable compromise that I think is slightly
>>>> less risky for the LLDs with the ghosts and cob-webs hanging off of
>>>> them.
>>>
>>> They won't get tested either next release cycle. Essentially
>>> near nobody uses them.
>>>
>>>>
>>>> What do you think..?
>>>
>>> Standard linux practice is to simply push the locks down. That's a pretty
>>> mechanical operation and shouldn't be too risky
>>>
>>> With some luck you could even do it with coccinelle.
>>
>> Precisely ... if we can do the push down now as a mechanical
>> transformation we can put it in the current merge window as a low risk
>> API change.
>
> I disagree that touching every single legacy LLD's SHT->queuecommand()
> and failure paths in that code is a low rist change.

Think of changes like steps in a math proof.  You want to make a series 
of equivalent transformations such that, each transformation takes the 
code (proof) one step closer to your goal.

unlocked_qcmds does nothing but increase complexity, as opposed to an 
equivalent-transformation mechanical code change much more easily 
provable as correct (or broken). unlocked_qcmds is the type of 
transition step you always want to avoid if possible.  Conditional 
locking logic tends to be complexity at its worst... and in this case, 
it's all avoidable.

	Jeff