[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.00.0802220843560.19896@woody.linux-foundation.org>
Date: Fri, 22 Feb 2008 08:50:04 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
cc: Matthew Garrett <mjg59@...f.ucam.org>,
Jeff Chua <jeff.chua.linux@...il.com>,
Jesse Barnes <jesse.barnes@...el.com>,
Romano Giannetti <romano@....icai.upcomillas.es>,
suspend-devel List <suspend-devel@...ts.sourceforge.net>,
Dave Airlie <airlied@...ux.ie>, Greg KH <gregkh@...e.de>,
lkml <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, linux-acpi@...r.kernel.org
Subject: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off
aftersuspend-to-disk. Screen becomes green.
On Fri, 22 Feb 2008, Ingo Molnar wrote:
>
> btw., why isnt there an in-kernel whitelist, with perhaps a dynamic,
> convenient /debug/s2r/whitelist append-API for distros (and testers) to
> add more entries to the whitelist/blacklist? (for cases where the kernel
> whitelist has not caught up yet) Which would eventually converge to
> Utopia: s2ram that just works out of box.
The big problem with that is
- the people who know about the devices are usually not kernel people
- the workarounds that the whitelist requires is quite often not a kernel
workaround.
In other words, the most common workarounds for the s2ram whitelist is
usually to do things like running vbetool in user-level to do VGA register
save/restore (VBE_POST and VGE_SAVE). Sure, the kernel could do that with
usermodehelper etc, but s2ram also has those things as command line flags
etc, so...
Linus
--
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/
Powered by blists - more mailing lists