On Thu, 2010-05-27 at 20:59 -0400, Alan Stern wrote: > On Fri, 28 May 2010, Rafael J. Wysocki wrote: > > > > And the forced-suspend design relies on the fact that processes remain > > > frozen throughout. If we leave some processes unfrozen and one of them > > > somehow becomes runnable, that means we have to abort the forced > > > suspend before the process is allowed to run. > > > > We could avoid that if drivers could block tasks, but there are questions to > > answer. First off, how a driver is supposed to know when to block the task > > using it and when to do its power management transparently for the task? > > Second, how to intercept and block all possible interfaces that user space > > can use to talk to drivers (how to intercept a task using mmapped device, for > > example)? > > We talked about this a few years ago and decided it was not feasible. > It would require substantial changes to every device driver. But what if its the _right_ thing to do? We make changes to every device driver out there on a regular basis. Also, why won't an incremental process work? Add the interface with a fallback for drivers that haven't implemented it and implement it for those drivers its most urgent (like those in use on an Android phone). Not doing the right thing simply because its a lot of work seems like a fine way to let the kernel rot into an unmaintainable mess. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
