--- Jeff Garzik <jeff@xxxxxxxxxx> wrote:
> James Bottomley wrote:
> > On Tue, 2006-05-16 at 12:06 -0400, Jeff Garzik wrote:
> >> Sigh. They clearly do not have the same effect, because the above code
> >> guarantees that a timeout is forced, regardless of whether the timer has
> >> fired or not. That in turn guarantees that the timeout callback
> >> (->eh_timed_out) is called, and the cmd is in a very specific state.
> >
> > the API claims to be forcibly aborting a command, which is *not* a
> > timeout ... trying to pretend to the midlayer that it is is the wrong
> > processing model. You may choose to call this API because of a class
> > internal timeout, but you don't need the callback notification that it
> > is a timeout in this case, you already know it is.
>
> I can certainly agree the name may not be the best choice. Naming based
> on implementation, it could be scsi_force_timeout_cmd() or somesuch.
But it is not that either!
As far as the LLDD is concerned, it is calling scsi_req_abort_cmd() to
request SCSI Core to abort it. At the point of LLDD calling this function
the command is not marked anything. This is important!
Why?
Because LLDD/interconnects
1. Do not want to race with SCSI Core changing the state of the command.
2. You want to give LLDD a chance as the command may finish in due time since
the interconnect requested it be aborted. I.e. there could be a race in the
transport too, which doesn't depend on the transport but on the end device, SDS,
and the transport.
For these reasons the best bet is to emulate a time out so that SCSI Core calls back
into the transport to tell the transpor that, it, SCSI Core, is about to start ER
on the command.
Then LLDD/interconnects have another chance, plus it gives notification to LLDD/IC
that SCSI Core has changed its disposition of that command.
Luben
-
: 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
