public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@zip.com.au>,
	torvalds@transmeta.com,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Dealing with swsusp vs. pmdisk
Date: Fri, 12 Mar 2004 19:47:56 -0500	[thread overview]
Message-ID: <20040313004756.GB5115@thunk.org> (raw)
In-Reply-To: <20040312224645.GA326@elf.ucw.cz>

On Fri, Mar 12, 2004 at 11:46:45PM +0100, Pavel Machek wrote:
> I don't really like having two implementations of same code in
> kernel. There are two ways to deal with it:
> 
> * remove pmdisk from kernel
>   + its easy
> 
> * remove swsusp from kernel, rename pmdisk to swsusp, fix all bugs
>   that were fixed in swsusp but not in pmdisk 
>   + people seem to like pmdisk code more
>   - will need some testing in -mm series
> 
> Which one do you prefer? I can do both...

2.6 is allegedly the stable kernel series, so if swsusp is the more
stable code base at this point, my vote would be to keep swsusp and
remove pmdisk from the kernel.  If someone wants to maintain a
separate BK-tree that contains pmdisk renamed to swsusp and fix all
the bugs, that's great.  On the other hand, there are a group of
people of are busy doing something very similar with swsusp2, and that
effort seems to have a fair number of people working on the patch and
testing it.  

So if we can somehow go from *three* idependent software suspend
implementations implementations to something less than three, and
increase the testing and effort devoting to remaining software suspend
code bases, this would be a good thing.

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.

						- Ted

  reply	other threads:[~2004-03-13  0:48 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 [this message]
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

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=20040313004756.GB5115@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=torvalds@transmeta.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox