Suspend2 isn't invasive.

[Matt Price]

On Fri, 2006-01-12 at 08:45 -0600, Travis Watkins wrote:
> On 12/1/06, Hervé Fache <Herve at lucidia.net> wrote:
> > As I said before on this list, one cannot judge suspend2 vs swsusp
> > until they try both, and I did. I started up with a biased stance
> > towards sticking to Linus' tree, but once you've tasted suspend2 it's
> > hard to go back to black screens and no info.
> 
> uswsusp can apparently give you the same thing here.
> 
> > I do believe people that tell me both use the same kernel resources,
> > but it's quite obvious that they use them in different ways. On
> > Dapper, I used to get the suspend2 kernels from Dagobah, and my work
> > machine was hibernated every night. It could not hibernate with stock
> > kernels. Neither could my wife's laptop until Suspend2.
> 
> With the stock kernel did they fail to hibernate or fail to resume?
> Big difference.
> 
with swsusp of course it can be quite hard to tell the differnce, as
there's no feedback durng the suspend process and no debugging code on
reboot.

> > My old laptop (small RAM small swap) could also hibernate with
> > suspend2 thanks to image compression, and the speed was quite good (a
> > few seconds).
> 
> This is a valid use-case for suspend2, I guess.
> 
> > I quite understand that Ben Collins has got more than his share of
> > work with the kernel, so I can understand a technical choice and do
> > not complain (please fix that KT400 bug ;-), but please don't tell us
> > swsusp is the same as Suspend2, because it would be the same a saying
> > an old VW Beatle is the same as a Merc.
> 
> Even Nigel says suspend2 and swsusp are the same as far as hardware
> compatibility goes.
> 
I don't think we should have a flame about how great/terrible suspend2
is.  I use suspend2 and like most users would love to have it in the
default ubuntu kernel, but at this juncture I'm not agitating for
inclusion.  I *am* hoping that infrastructure can be put together making
it as easy as possible for users to switch to suspend2 if they want/need
to.   One important consequence of this would be a reservoir of user
experience to draw upon on the day that suspend2 is finally fully merged
into the vanilla kernel.  I think the important elements of such a
strategy are:

1) a git branch that tracks suspend2 and ubuntu.  Apparently Nigel
already has this!
2) kernel packages that include suspend2.  I am working on these though
honestly I don't think I'm the right choice to maintain them as I don't
program in C and have just in the last week or so learned what a
Makefile is.  Hopefully Bernard will take this in hand when he has time.
3)A linux-source package patched with suspend2 to let people hack on and
manually configure the patched source. I'm not sure how to generate this
but it looks relatively simple.
4) An additional target in debian/rules for linux-restricted-modules,
and some obvious configuration variables at the top of the script,
making it clear how to build the package for a custom kernel.
5) implementation=-gnostic power-management infrastructure that supports
all three suspend implementations.  Again, this will pay off in the
future anyway when we switch to one of the other suspend methods as a
default.  Scott's overview
(https://wiki.ubuntu.com/FeistySuspendOverview) is a good start but one
thing it demonstrates is that the current infrastructure is a little
convoluted; I don't know whether someone should draft a spec proposing
changes?  Scott, Matthew, does this interest either of you?  

All in all this doesn't look so bad.  (1) is done, (2) and (3) shouldn't
be that hard to do (just need to go from successfully building one
kernel to systematically building the dozen or so that would be needed);
(4) also looks like it won't take that much work, though I don't know
that Ben ought to let someone like me loose on l-r-m's debian/rules
script; (5) looks to be a fair bit of work but could hopefully be
co-ordinated between a number of people.  

matt

> -- 
> Travis Watkins
> http://www.realistanew.com
> 
-- 
Matt Price
History Dept
University of Toronto
matt.price at utoronto.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20061201/6520459d/attachment.pgp