On Fri, 28 May 2010, Peter Zijlstra wrote: > 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). There is no reasonable fallback. In fact, I seriously doubt that there's any way to carry this out at all, reasonable or not. For example, how do you handle the situation where a user task gets an error because it accessed an mmapped address belonging to a device that has been suspended? > 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. Firstly, it's not at all clear that this _is_ the right thing. Secondly, when doing the right thing involves making invasive changes to half the .c files in the kernel, people might stop to think that it would add more bugs than it would solve problems. Alan Stern -- 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
