Messages in this thread | | | Date | Tue, 14 May 2002 14:03:39 +0100 | From | Neil Conway <> | Subject | Re: [PATCH] 2.5.15 IDE 61 |
| |
Alan Cox wrote: > If the queue abstraction is right then the block layer should do all the > synchronization work that is required.
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/
| |