Re: [RFC] current libata eh doc

[Tejun Heo <htejun@gmail.com>]

Jeff Garzik wrote:
> Tejun Heo wrote:
> 
>> Jeff Garzik wrote:
>>
>>> I would note that ->complete_fn() is the asynchronous path, and 
>>> qc->waiting is the synchronous (sleeping in process context) path.
> 
> 
>>  Okay.  One question though.  Is it necessary to keep these two 
>> separate?  qc->waiting can easily be implemented in terms of 
>> ->complete_fn() if we add a void *udata argument to it.  Is there any 
>> design consideration I'm not aware of?
> 
> 
> 
> Synchronous usage (use of qc->waiting) is common and growing more 
> common, so it seemed expedient to put 'waiting' in the data structure. I 
> also thought it might be nice to have the completion occur after the 
> ->complete_fn() callback and tag poisoning occurred.
> 
> Certainly qc->waiting can be implemented in terms of ->complete_fn(). 
> But unless unseen elegance (or bug fixes) will result, I'm not terribly 
> inclined to change it.
> 

  The problem with qc->waiting is that it currently doesn't have anyway 
to pass command result when waking up the issuer.  We currently do this 
by reading ATA registers from the issuer after being woken up.  This is 
fine for EH, but, for multi-qc translation, this can be done but is a 
bit cumbersome.

  Also, we're gonna need to pass more information when a command fails 
if advanced EH is implemented.  We can add an extra per-qc/device error 
descriptor to be used by synchrnous completion, but these can be done 
much elegantly with ->complete_fn() w/ an opaqueue pointer.

-- 
tejun