Re: [RFC] New Driver Model for 2.5

[Alan Cox]

> upon must be stopped after you. That's the point of having a
> tree here. Patrick and Linus feel the bus tree is enough to handle
> that dependency, which might well be the case for 99% of drivers.

The two trees are certainly closely related - USB devices before USB hub,
USB hub before PCI etc. The scanner example works fine there, providing that
we are careful about memory issues - remember the USB layer allocates memory
to do any transaction, so the scanner has to complete its state save before 
we do any interrupt disabling/memory alloc freezing.

Thats still just ordering and maybe two passes

> the HW or not when getting a new request). In cases where a mid-layer
> enters the scene, like SCSI, that wants to do timeouts, then well...
> we can let it timeout (just stop processing requests), or we can
> have the midlayer go to sleep as well :) That later solution
> may cause some interesting ordering issues however...

For scsi you have to complete the pending commands, you don't know what the
transaction granularity is in some cases and half completing the sequence
won't help you. In addition the upper layers have to queue additional scsi
commands to do stuff like cd drawer locking and to ask the drive firmware
to enter powerdown modes

> For USB, for example, we can consider that when a device driver
> (not a controller driver) suspend has been done, any URB it submits
> can just be dropped (returned immediately with an error). We don't
> need blocking here neither. Of course, that means we have the
> framework to call devices' suspend/resume callbacks when the
> controller is about to go to sleep.

That will scramble large numbers of devices. Randomly erroring pending block
writes is -not- civilised.

Alan