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
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
