[Pm-utils] [PATCH 6/7] This patch adds framebuffer console handling routines.
seife at suse.de
Wed Feb 13 08:22:38 PST 2008
Michael Biebl wrote:
> 2008/2/13, Victor Lowther <victor.lowther at gmail.com>:
>> It is the only thing that we were missing from the s2ram tools.
> Serious question: Why don't we just use s2ram at first place instead
> of reimplementing the functionality? I mean, we already rely on
> external packages (vbetools) for the video handling stuff, so we could
> just as well rely on s2ram *instead*.
> Is it, because s2ram comes bundled together with s2disk and you don't
> want to use userspace hibernate? In that case, we could split s2ram
> and s2disk into separate binary packages.
> Imho using s2ram (with the quirks provided by hal, and optionally
> fallback to the builtin whitelist) seems like a good solution.
That's what i had suggested a _long_ time ago already.
> I'm sure, Stefan also has some good technical arguments, why it's a
> good idea to do the video state store/restore in a single binary.
Yes, and i have written them down a thousand times. But nobody seems
Basically the arguments are:
- you don't need storage for e.g. vbetool vbestate save
- it is less prone to race conditions (and it could be improved to make
them go away by locking the VT switching)
- less dependencies
- (not done yet): you could mlock() it, so that it actually resumes
machines that kill their harddrive during suspend, so that they are
more easily debugged.
But i am sure there are much more arguments on this mailinglist that show me
that i am totally wrong and not knowing what i am doing wrt. suspend to ram :-)
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
More information about the Pm-utils