--- Jeff Garzik <jeff@xxxxxxxxxx> wrote:
> (CC's restored)
>
> James Bottomley wrote:
> > 1) your host_eh_scheduled logic looks wrong. It seems to me that you
> > can miss the wakeup if the host is busy? I also don't see a need to
>
> I can't see a case _in libata operation_ where a set of circumstances
> arises that causes missed wakeups, can you elaborate?
>
>
> > move the prototype out of scsi_priv.h ... it should only be used by
> > transport classes, anyway.
>
> We're talking about all ->eh_strategy_handler() users, which is a valid
> EH API for an LLDD to choose. Granted libata is really the only one
> right now.
>
> Long term, ->eh_strategy_handler and transport classes are block layer
> not SCSI level anyway, so scsi_priv.h is clearly inappropriate.
The physical stack (HW) looks like:
Block ->
SCSI ->
Transport ->
Interconnect ->
Device.
Not sure how you're going to achieve a SW abstraction whereby
"->eh_strategy_handler and transport classes are block layer",
when, the HW abstraction is different.
Luben
>
>
> > 2) This scsi_req_abort_cmd() is fundamentally the wrong logic.
> > Everything else is communicated back as a result code from the command
> > in done(). This should be no different ... A status return of
> > DID_FAILED which scsi_decide_disposition() always translates to FAILED
> > would seem to do exactly what you want without all the overhead.
>
> Inigo sez[1]: I do not think "fundamentally wrong" means what you think
> it means.
>
> You miss the fact that the timer may have already fired, in which
> completing a command gets you...... not a damned thing. scsi_done()
> will simply return, if the timeout has fired. This has always been an
> annoying problem to work around.
>
> scsi_req_abort_cmd() may perhaps be misnamed, but it GUARANTEES a set of
> operations which libata EH wants. Certainly, if we can guarantee this
> set of conditions another way, we are open to any alternate path.
>
> Jeff
>
>
> [1] from one of my favorite movies. search
> http://us.imdb.com/title/tt0093779/quotes for "INCONCEIVABLE"
> -
> : 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
>
-
: 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
