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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1275031197.32462.14.camel@laptop>
Date:	Fri, 28 May 2010 09:19:57 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/