Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux