On Wed, 2005-03-09 at 11:11 -0500, Alan Stern wrote: > On Tue, 8 Mar 2005, Adam Belay wrote: > > > The idea here is that if a device could be put into a lower state in which > > it isn't operational, but still maintains configuration, then we could just > > use "close" and "open". For complete poweroffs we could do: > > > > "close" -> "stop" and... "start" -> "open". > > > > A power state has the following characteristics: > > Is the device operational? > > Is the context of the device maintained? > > Is the configuration of the device maintained? > > > > "start" and "stop" handle configuration, "open" and "close" handle context. > > You would end up imposing your own three-layer set of power states on > devices for which it might not be appropriate. Many devices would only > support one or two of those layers; the rest would be wasted. Other > devices might have even more finely-grained power distinctions. Not at all, these layers correspond to the existing driver model design, which, to date, has been adequate for every type of device. Class devices are optional. If the driver registers many class devices, then the driver model could automatically manage "*start" and "*stop" for all of them. If none are registered, then there is no extra overhead, and no extra layer. If you're referring to "start" and "open" as "layers", then I don't think they're imposing anything unreasonable. Every driver needs to detect and setup the hardware (*start) and most drivers need to make that device available to the user or other kernel components (*open). More fine grained layers would be class specific and happen after *open, which essential prepares the device for use by the class. > > I think it's better to keep the central PM model as simple as possible and > leave complicating details to the individual drivers and to userspace. 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. In early Linux code, PCI drivers had the option to implement everything their own way (from driver matching to resource configuration). This sort of model had a lot of problems and now we have a PCI bus layer which scales much better. I think power management is a similar situation. PCMCIA is another example, as the various deadlocks and resource management difficulties shows how too much userspace control can be a bad thing. Recently, it was redesigned to support in-kernel device matching (a move away from userspace control). I think it's important that we consider past designs, and find a good compromise between centralization, individual driver control, and userspace involvement. Thanks, Adam
