On Thu, 2005-08-25 at 11:27 -0400, Alan Stern wrote:
> But it complicates the structure of drivers by forcing them to use a
> state-machine approach with a bunch of tedious intermediate states ("link
> change request issued, waiting for notification").
Not necessarily. The driver could do synchronous blocking wait if it's
not running inside the context of the iterator thread which won't be the
case most of the time.
> It also introduces
> complications from the possible arrival of several change requests or
> notifications at once, since there's no locking to guarantee mutual
> exclusion among them.
Who else but the driver is allowed to request a link state change on the
device ? That specific race can be dealt with or considered as a
programming error.
> Device removal racing with power state changes. During device
> removal the PM lock should be held; this will prevent the two
> operations from overlapping. You might end up trying to carry
> out a power-state change on an already-removed device; that's
> not a problem -- it will simply fail.
Those locks are a wonderful deadlock scenario as soon as the driver end
up triggering add/remove events while they are held and that does
happen. I'm really not fan of those global and/or cascaded locks, I find
the approach very deadlock prone.
