Jeff Garzik wrote: > An alternate arrangement, not presented by this patch, might > be preferred: in order to make it clear that queuecommand > locking has changed, one could s/queuecommand/queuecommand_nl/ in > Scsi_Host_Template, in order to guarantee that drivers are either > (a) upgraded or (b) broken at compile time. Compile-time detection of > new locking may be desirable, and I'll volunteer to change my patch to > do that, if community members prefer that route instead of below. I followed only a fraction of the related discussion. Thus I wonder why a renaming of scsi_host_template.queuecommand was not part of these attempts from the very outset. Given the choice between compile-time breakage of unconverted drivers and silent invalidation of potential locking assumptions at runtime, the preferable way forward is quite clear IMO. (Since no coexistence period of .queuecommand and .queuecommand_nl or .unlocked_queuecommand is planned, how about you rename it to .queue_command? Follows Linux naming conventions more closely.) -- Stefan Richter -=====-==-=- =-== --==- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
