On Wed, 9 Mar 2005, Adam Belay wrote: > 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? I'm not clear on the distinction you draw here between context and configuration. Also you should note that some drivers have to keep track of much finer levels of functionality than just "is it operational". For instance: which parts are operational, which clocks are running, what is the speed, and so on. > > > "start" and "stop" handle configuration, "open" and "close" handle context. > 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. Let's not worry about class devices for now. Are your start/stop and close/open significantly different from probe/remove and suspend/resume? > 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. Alan Stern
