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.
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.
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?!]]
The right way is the way it is being done at present surely: if the busy
flag on the hwgroup is set, then ide_do_request() just returns. (NB:
When I say "right way", I don't mean to imply that the code is elegant,
desirable, or even bug-free, just that it correctly handles this busy
state.)
>It may cost a few cycles on the odd
> case you can do overlapped command setup but that versus a nasty locking
> mess its got to be better to lose those few cycles.
Well, Jens and others are busy implementing TCQ where things are just so
much easier to fsck up :-))
> I don't even Martin here, the ide locking is currently utterly vile
Agreed, but surely with some concerted effort we can truly fix the IDE
code. Can't be beyond us all can it?
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/