Re: [patch 4/6] ide: allow ide_dev_read_id() to be called from the IRQ context

[David Miller <davem@davemloft.net>]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
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.