From: Jan Rychter <jan@rychter.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Dealing with swsusp vs. pmdisk
Date: Thu, 18 Mar 2004 02:21:43 -0800 [thread overview]
Message-ID: <m2n06ee9qg.fsf@tnuctip.rychter.com> (raw)
In-Reply-To: 20040313122819.GB3084@openzaurus.ucw.cz
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
>>>>> "Pavel" == Pavel Machek <pavel@ucw.cz> writes:
[...]
Theodore Ts'o <tytso@mit.edu>:
>> Pavel, what do you think of the swsusp2 patch, BTW? My biggest
>> complaint about it is that since it's maintained outside of the
>> kernel, it's constantly behind about 0.75 revisions behind the
>> latest 2.6 release. The feature set of swsusp2, if they can ever
>> get it completely bugfree(tm) is certainly impressive.
Pavel> My biggest problem with swsusp2 is that it is big. Also last
Pavel> time I looked it had some ugly hooks sprinkled all over the
Pavel> kernel. Then there are some features I don't like (graphical
Pavel> screens with progress, escape-to-abort) and
Pavel> ithasvariableslikethis. OTOH it supports highmem and smp.
It also has the advantage of working extremely reliably on 2.4 (and a
large part of the code base is shared, so that's a significant data
point). I couldn't get it to crash or do anything bad for months now,
and I'm doing at least several suspend/resumes a day on my laptop.
Also, thanks to the excellent compression feature, suspend/resume times
are very short and in fact competitive with suspend-to-ram schemes.
I think it's better not to mix personal preferences (such as the
escape-to-abort thing) with technical discussions. On a practical level,
swsusp2 is the only implementation which works reliably, does its job
very well, and has a responsive maintainer willing to fix problems as
they arise.
--J.
[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
prev parent reply other threads:[~2004-03-18 10:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-12 22:46 Dealing with swsusp vs. pmdisk Pavel Machek
2004-03-13 0:47 ` Theodore Ts'o
2004-03-13 2:51 ` Benjamin Herrenschmidt
2004-03-13 12:36 ` Pavel Machek
2004-03-13 22:19 ` Micha Feigin
2004-03-14 0:18 ` Benjamin Herrenschmidt
2004-03-14 0:37 ` Pavel Machek
2004-03-15 20:05 ` Nigel Cunningham
2004-03-16 0:01 ` Benjamin Herrenschmidt
2004-03-15 23:31 ` Nigel Cunningham
2004-03-16 1:40 ` Benjamin Herrenschmidt
2004-03-15 23:59 ` Nigel Cunningham
2004-03-16 10:09 ` Pavel Machek
2004-03-13 12:28 ` Pavel Machek
2004-03-15 23:17 ` Jan Rychter
2004-03-16 18:16 ` Kevin Fenzi, Kevin Fenzi
2004-03-18 10:21 ` Jan Rychter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2n06ee9qg.fsf@tnuctip.rychter.com \
--to=jan@rychter.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.