Messages in this thread | | | Date | Sun, 07 Nov 2010 11:54:22 -0500 | From | Jeff Garzik <> | Subject | Re: [RFC PATCH] SCSI host lock push-down |
| |
On 11/06/2010 05:31 AM, Stefan Richter wrote: > 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.
I am leaning towards a rename, but wanted to see what others thought.
> (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.)
To me, that name lacks a clear "locking changed" signal, for a random engineer who simply stumbles upon the queuecommand -> queue_command rename change one day.
Jeff
| |