Re: [Fwd: [RFT] major libata update]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- 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

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux