Re: [RFC] New Driver Model for 2.5

[Eric W. Biederman]

Benjamin Herrenschmidt <[e-mail]> writes:

> >> case, there's not much left to the controller, it isn't supposed to
> >> have any command in queue nor receive any new one once all it's child
> >> drivers have suspended.
> >
> >scsi devices are children of the scsi subststem (sd, sg, sr, st, osst) not
> >of the controller. That is how the state flows anyway. Only sr/sd etc know
> >what the state is for a given device on power off as they may issue 
> >multiple requests per action true transaction. sg would have to simply
> >refuse any suspend if open (think about cd-burning or even worse firmware
> >download)
> >
> >So the scsi devices hang off sd, sr etc which in turn hang off scsi and 
> >the controllers hang off scsi (and or the bus layers)
> >
> >This one at least I think I do understand
> 
> The problem with subsystems is that they don't fit well in the
> power tree. They aren't "devices" in that sense that they are
> not exposing a struct device, and they spawn over several controllers
> which means the dependency can quickly become unmanageable, especially
> when SCSI starts beeing layered on top of USB or FireWire.
> 
> Also, the dependency issue is made worst if you let RAID enter into
> the dance as I beleive ultimately, nothing would prevent a volume to
> spawn over several devices from different controllers or even different
> controller types. 

On the dependency case for x86 I have a fun common example.
To shut off the cpu, or the whole motherboard I need to talk to the
southbridge.  To talk to the southbridge, I need to talk to the northbridge.

So at least to some extent shutting down busses is a really different
case from shutting down devices.  And only in some cases can a tree
model it at all.

Equally fun are temperature monitors that appear on both the lpc/isa bus
and the i2c bus.

Or another fun common one.  To shut down the interrupt controller, I first
need to shut down every device that thinks it can generate interrupts.
But my interrupt controller is way out on my pci->isa bridge.  So I
can't shut that device down.

Sorry this whole device tree idea for shutdown ordering doesn't seem
to match my idea of reality.

Now I need to take a little time out and see what the code that is
being discussed will actually do about situations like the above.

> A tricky issue indeed...

Agreed.

Eric