Phew, at least we agree on something. In fact I _think_ we were maybe
talking at cross-purposes and not disagreeing about anything that
actually mattered :-)
> > It doesn't matter how you perform the queue abstraction in this case:
> > the fact that the device+channel+cable is busy in an asynchronous manner
> > makes it impossible for the block layer to deal with this. [[Or am I
> > way off base?!]]
>
> I think you are way off base. If you have a single queue for both hda and
> hdb then requests will get dumped into that in a way that processing that
> queue implicitly does the ordering you require.
Hmm, OK. So the queue will potentially fill up with requests for both
hda and hdb. The request_fn for this queue will get called, sometimes
by the block layer, sometimes not, and can handle all/some/none of the
requests at each call. If it decides to handle (say) one of the
requests by initiating DMA and then returns while bytes are
transferring, then let's think what happens next time it gets called...
If it's called as a result of the DMA-complete interrupt, then no
worries because the DMAing is finished. If it's called instead by the
block-layer because another request has been added, it needs to know
that it shouldn't do anything until the DMAing finishes. It could find
that out by looking at a channel->busy flag. If it doesn't use a busy
flag, then what provides the locking?
I'm slowly growing more sure that I've missed the point. But please
point to the mistake in the above logic to help me learn...
> From an abstract hardware point of view each ide controller is a queue not
> each device. Not following that is I think the cause of much of the existing
> pain and suffering.
Agreed. And in the case of a cmd640 (etc.), the queue should handle
both channels.
cheers
Neil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/