Re: [PATCH / RFC] scsi_error handler update. (1/4)

[Mike Anderson <andmike@us.ibm.com>]

Christoph Hellwig [hch@infradead.org] wrote:
> > That is, eh_* functions of a LLDD should be re-entrant.
> 
> Agreed that they should.  The question on how to implement this
> without breaking drivers remains.  Do you volunteer to do add taking
> the lock into all these methods so the existing lock state remains until a
> maintainer ACKs that his driver doesn't need protection / and or makes
> it reenetrant?
> 
> The other way would be to add an concurrent_eh flag to the host template,
> but I really hate these conditional locking schemes, they just cause confusion.
> 

The host template check may cause confusion, but today we have few
drivers that do not need the host_lock taken so we end up with code
bloat and confustion in the drivers to support a older model:
	- Mid takes lock with flags
	- LLDD drops lock and then grabs it again before return.
	- Mid drops lock with flags.

> > While we are this I'd like to give this idea to you, which I've
> > mentioned before (this will be kind of more formal):
> > 
> > Proposal A: Let's make queuecommand() be void queuecommand().
> > 
> > This will accomplish the following:
> > 	- the only way SCSI Core gives ownership of a scsi command
> > 	structure to a LLDD is by calling queuecommand() -- which
> > 	is currently the case as well.
> > 
> > 	- the only way a LLDD gives ownership back to SCSI Core is
> > 	by calling scsi_done(), and let there be *no* other way.
> > 
> > I completely detest the current dualist approach of also checking
> > the return value of queuecommand().
> 
> That sounds nice to me.  But again, do you think you can do it for 2.5
> without breaking more drivers?  (i.e. fixing everything up)
> 

I like the idea, but for 2.5 cleaning the ~95 queuecommand functions
seems large.

> > As to the eh_* routines:  The current naming technique follws SPI,
> > which is now out of SAM and SPC.  Furthermore newer SCSI devices,
> > not necessarily on a parallel interface, do not define bus_reset,
> > host_reset and sometimes device_reset, because it is not
> > always clear what is the device or host or bus...
> > 
> > Proposal B: let the eh_* become tmf_* where TMF is
> > Task Management Functions.  Those are from SAM-2/3 (all re-entrant):
> > 
> > int tmf_abort_task(scsi command pointer);
> > 	aborts the task sent from this initiator port,
> > 	the LLDD will determine the initiator port.
> > int tmf_abort_task_set(target, lun);
> > 	aborts all tasks sent from this initiator port,
> > 	like sending multiple tmf_abort_task(...).
> > int tmf_clear_aca(target, lun);
> > int tmf_clear_task_set(target, lun);
> > int tmf_lun_reset(target, lun);
> > int tmf_query_task(scsi command struct);
> > int tmf_target_reset(target);
> > int tmf_wakeup(target);
> > 
> > Some of those are optional and depend on the functionality of the
> > device. Others depend on the transport.
> > 
> > The result of the function is the service response which is one of:
> > { TMF_COMPLETE, TMF_SUCC, TMF_REJ } and Service delivery or target failiure.
> > 
> > I think that this framework will also be very convenient for the USB
> > people, since they will not define all of those, but the ones they will
> > define, they can map easily to their own USB infrastructure.
> > 
> > ``target'' is a target identifier (type not known at this point).
> > ``lun'' is a 64 bit quantity.
> 
> It should be the same type as is used for luns in other places of the
> scsi midlayer (whatever that m,ay be when this gets in)
> 
> > All those methods are to be re-entrant and a command could be cancelled
> > all the while the LLDD continues to process commands.  (I've done
> > this myself.)  This would warrant a bit different queueing technique
> > in SCSI Core but slowly we're getting there.
> > 
> > Maybe this is 2.7 stuff, but as long as ideas are popping up, we're doing
> > okay.
> 
> I think that's clearly 2.7 stuff, we've moved scsi a lot forward in 2.5,
> now we need to get most drivers working again and 2.6 out of the door.
> 
> If you have anough time a prototype now won't hurt though - the scsi code
> shouldn't really change during early 2.6.
> 

I also agree about it being a 2.7 item, but I like it as a guide of
where we should consider heading.

-andmike
--
Michael Anderson
andmike@us.ibm.com