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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
