quoted

You want the ancestral relationship for several reasons. You'd wouldn't
power down such a device on PM transitions or during shutdown, but you
would stop I/O transactions. The drivers for these devices should recogize
it's a remote device and handlethis. And, if you were to remove the bridge
device (the network card, etc), you want the devices behind it and their
logical mappings to go away gracefully.

Ok, so what's your take on: NBD (iSCSI without all the SCSI crap),
software RAID, LVM, ramdisk, partitions (a degenerate case of volume
management), loopback, and filesystems. All but the last are block devices
that want to be treated just like disks and will want to know about things
like PM transitions, etc. Filesystems haven't made it into the tree
because we've got that info elsewhere and we've been assuming they're
leafnodes, but if we put loopback devices on top of them, that's no longer
the case. It'd be cleaner globally if this were all explicit in the driver
tree.

This is a topic that has come up several times in the last couple days in 
Ottawa. I don't promise to have a complete solution, but this what I have 
so far:

You have two things: a physical device and a number of logical interfaces
to communicate with the device. iSCSI devices, local disks, video devices, 
mice, and joysticks are all physical devices and deserve a place in the 
device tree. 

RAID, LVM, DRI, and the input layer are all logical interfaces to physical 
devices. The drivers are the conduit between the logical and the physical. 
Drivers register devices with the logical interfcaces as their attached. 
It's up to the driver to register with the interfaces, which they already 
do. If registration gets generalized and centralized, you get internal 
linkage between the interfaces and the devices. This is essentially the 
device class voodoo that I've been talking about. 

Concerning power management, if we have a list of interfaces, and each had 
a suspend callback, you could notify the interfaces before you walked the 
device tree. Maybe this could take care of verifying the devices can 
suspend and failing if it's doing I/O that's too important to stop. 

[ We could also create a swap interface that we skip over when we notify 
these interfaces. Then we walk the tree and save state to the swap 
devices. Then, tell the swap devices to suspend, which can notify the 
devices to actually go to sleep....maybe..]

	-pat