On Wed, 2010-10-27 at 11:06 -0700, 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. It can be done mechanically. > > This gives us optimal exposure to the rc sequence to sort > > out any problems that arise (or drivers that got missed) with the lowest > > risk of such problems actually arising. > > Yes, > > > Given the corner cases and the > > late arrival of fixes, the serial number changes are just too risky for > > the current merge window. > > I think with andmike's testing and ACKs for the necessary scsi_error.c > changes this would be an acceptable risk. I already said why I didn't like this change. Without the serial number, there's no problem. > > Having an API that changes depending on a > > flag is also a high risk process because it's prone to further sources > > of error. > > > > I think this would be considered high risk if the setting of the flag > explictly was required to obtain the default legacy operation. With > this series that is not the case, as the default SHT->unlocked_qcmd=0 > will allow legacy LLDs to function exactly the manner they expect, while > allowing modern LLDs to run in host_lock-less mode. Having a variable API based on a flag elsewhere is always a bad idea. James -- 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
