On 11/10/2010 06:45 PM, James Bottomley wrote:
On Wed, 2010-11-10 at 18:28 -0500, Jeff Garzik wrote:
On 11/10/2010 05:40 PM, James Bottomley wrote:
Your commit:
[SCSI] host lock push-down
Move the mid-layer's ->queuecommand() invocation from being locked
with the host lock to being unlocked to facilitate speeding up the
critical path for drivers who don't need this lock taken anyway.
The patch below presents a simple SCSI host lock push-down as an
equivalent transformation. No locking or other behavior should change
with this patch. All existing bugs and locking orders are preserved.
Minimal code disturbance was attempted with this change. Most drivers
needed only two one-line modifications for their host lock push-down.
Signed-off-by: Jeff Garzik<jgarzik@xxxxxxxxxx>
Signed-off-by: James Bottomley<James.Bottomley@xxxxxxx>
has been added to the upstream SCSI tree
You can find it here:
No comments on renaming ->queuecommand to something else?
What we wondered about doing differently isn't really relevant for a
change log ... that should just really be about what was done (to avoid
confusion).
Wasn't referring to the changelog (perhaps shouldn't have quoted that);
just asking the question generally.
The consequences are rather dire if this goes unnoticed, yes?
You mean if there's a missed in-tree driver? Yes, but I took care to
make sure all SCSI drivers were accounted for. For out of tree drivers,
as with the eh lock push down, it's caveat emptor.
Thinking about out-of-tree drivers, yes.
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
