Re: [PATCH] libata error handling fixes (ATAPI)

Jens Axboe
2005-11-15T12:00:16Z

On Tue, Nov 15 2005, Jeff Garzik wrote:
> >For departure of libata from SCSI, I was thinking more of another more
> >generic block device framework in which libata can live in. And I
> >thought that it was reasonable to assume that the framework would supply
> >a EH mechanism which supports queue stalling/draining and separate
> >thread. So, my EH patches tried to make the same environment for libata
>
> A big reason why libata uses the SCSI layer is infrastructure like this.
> It would certainly be nice to see timeouts and EH at the block layer.
> The block layer itself already supports queue stalling/draining.

I have a pretty simple plan for this:

- Add a timer to struct request. It already has a timeout field for
SG_IO originated requests, we could easily utilize this in general.
I'm not sure how the querying of timeout would happen so far, it would
probably require a q->set_rq_timeout() hook to ask the low level
driver to set/return rq->timeout for a given request.

- Add a timeout hook to struct request_queue that would get invoked from
the timeout handler. Something along the lines of:

- Timeout on a request happens. Freeze the queue and use
kblockd to take the actual timeout into process context, where
we call the queue ->rq_timeout() hook. Unfreeze/reschedule
queue operations based on what the ->rq_timeout() hook tells
us.

That is generic enough to be able to arm the timeout automatically from
->elevator_activate_req_fn() and dearm it when it completes or gets
deactivated. It should also be possible to implement the SCSI error
handling on top of that.

--
Jens Axboe