On Fri, May 27, 2005 at 03:48:40AM -0400, Jeff Garzik wrote: > Christoph Hellwig wrote: > >On Fri, May 27, 2005 at 12:32:07AM -0400, Jeff Garzik wrote: > > > >>SCSI EH processing already serializes things during EH, so this spinlock > >>isn't really needed. > >> > >>Removing the spinlock outright would break drivers that surround logic > >>with spin_unlock_irq()..spin_lock_irq(), so I introduced ->unlocked_eh > >>option. > > > > > >Linus has vetoed such conditional locking in the past. However if you do > >it don't make it EH specific but introduce a ->concurrent flag that > >disables > >taking host_lock for ->queuecommand aswell. > > Such a 'concurrent' flag violates Linus credo "do what you must, and no > more." It's also silly and much too invasive. > > Removing the locking from the EH routines (only), and fixing up all > necessary drivers, is much more appealing. No, hav ing the host_lock only held for ->queuecommand which doesn't need that locking doesn't make any sense. An API like the current one where we take the lock over all run-time entry points makes some sense, and one where we don't take the lock at all makes lots of sense. One where we take the lock where it hurts most but not in the other cases doesn't. - : 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
