[Pm-utils] [PATCH 6/7] This patch adds framebuffer console handling routines.

[Stefan Seyfried]

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
interested :-)

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 :-)

Have fun,

	Stefan
-- 
Stefan Seyfried
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)