> I think you're wrong Alan. Take a good IDE chipset as an example: both
> channels can be active at the same time, but you still can't talk to one
> drive while the other drive on the same channel is DMAing.
Sure.
> I'm not a block layer expert, but it appears to me that the block layer
> only synchronises requests by use of the spinlock. If I'm right, then
> the block layer has no way of knowing that hda is DMAing when a request
> is initiated for hdb. This was the whole reason (as I see it) that
> hwgroup->busy existed: to prevent attempts to use the same IDE cable for
> two things at the same time.
The newer block code has queues. Its up to the block layer to deal with
the queue locking.
> 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.
>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.
Alan
-
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/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:23 EST