On Thu, 10 Mar 2005, Alan Stern wrote: > > I'm worried that if we have a too simplistic central PM model, then > > there will be very complicated difficult to maintain code in each > > driver. I'm in favor of a layered design. I don't think that one > > component should have to be aware of the details of other components. > > We lose a small amount of flexibility, but gain consistency and more > > structure. In the long run, I think this is more important for power > > management functionality. > > > I think it's important that we consider past designs, and find a good > > compromise between centralization, individual driver control, and > > userspace involvement. > > I agree. I just don't understand in what ways your proposal differs from > what we currently have. Because it makes it explicit what the actions are at each step, distinguishing the operations on the physical bus-based device from the logical class-based device. probe/remove and suspend/resume are actions for the physical device. They are likely to touch the bus-specific hardware of the device (e.g. control registers). start/stop and open/close are operations for the logical device. For each logical device, and recall that there can be multiple and even arbitrary numbers of logical devices per physical device. They do not control the physical state of the device, and while they may touch hardware registers, those are going to be MMIO-like registers, rather than e.g. PCI or USB specific registers. The distinction makes sense, mainly because it's already present, though not explicitly codified. Take a look at the eepro100, e100 or e1000 drivers. There is a point during ->probe() (as with many net drivers, I assume) where the function stops setting up the device and starts enabling features. That's where you would draw the line from ->probe() to ->start(). Making the separation has a few benefits (note none of which are critical, or else we would have done it already). Devices that have a (current, potential) arbitrary set of logical devices can have them all created and ->start()'d in parallel. (Video devices or complex networking devices are likely to have an arbitrary number.) We can completely remove a logical-device subsystem module, without having to remove every single driver (e.g. the DRM, fbdev, or future video interfaces) and reinsert them. And, it forces a divorce of the physical from the logical in the drivers, making them more compartmentalized and hopefully easier to deal with. Does that help? Pat
