From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> Date: Wed, 24 Jun 2009 11:51:16 +0200 > You've put less than 2h (because that was the time since my post till your > reply) into analysis of the bug, the related problems and the solution. > > It could be that if you had put a bit more time into it and/or asked detailed > technical questions related to the solution (i.e. "Why x needs to be there > and we can't do y?") instead of keeping the technical discussion on the very > vague level (which sounded like "can't we use block layer to process block > requests because drive commands are block requests and raw commands are drive > commands so we should use block layer") you would come to very different > conclusions than you did initially. I'm investigating alternative ways to this problem, less because of the time I put into the investigation, but moreso because I'm able to put fresh eyes onto the problem. And also I don't know the IDE code as well as you do, which is an advantage insofar as not falling into "oh I know how this stuff works, therefore we can't..." kinds of mental traps. Back to the technical side, ignoring the interrupt-or-not uglies, there are two other reasons why using synchronization is better here: 1) You want the device to be quiescent anyways when you do this SET_XFER command. What better way than to plug the queue and make sure all currently outstanding requests complete? And as already discussed, we even already have logic to support this kind of thing for the sake of power-management. 2) All commands going into the device do so from a context from which we could take a sleeping lock such as a mutex. It's therefore the most natural way to synchonize things. I know you're busy, so I'll try to draft something up myself. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
