|| ||Nigel Cunningham <nigel-AT-tuxonice.net> |
|| ||Bartlomiej Zolnierkiewicz <bzolnier-AT-gmail.com> |
|| ||Re: [RFC] TuxOnIce |
|| ||Sat, 09 May 2009 07:59:31 +1000|
|| ||"Rafael J. Wysocki" <rjw-AT-sisk.pl>, linux-pm-AT-lists.linux-foundation.org,
Pavel Machek <pavel-AT-ucw.cz>|
|| ||Article, Thread
On Fri, 2009-05-08 at 21:44 +0200, Bartlomiej Zolnierkiewicz wrote:
> Please proceed to Plan B then.
> Adding third core code framework to do the same thing is out of question
> (probably same should have been said about adding second one in the past).
Why? We have plenty of history of having multiple implementations of
things (slub, slab and slob...).
> Moreover you will for sure hit much more regressions than you expect
> (I "love" seeing over and over again when people/companies get trapped
> into fallacy of superiority of their _own_ solution).
That's just wrong. TuxOnIce deliberately doesn't remove any of swsusp or
uswsusp so that there's no chance of users having regressions. It
provides the _option_ of being a drop in replacement for swsusp, but it
doesn't force users to take that option.
Regressions happen at the moment because TuxOnIce isn't included in
vanilla. Users update from one version of stable to the next or from one
version of head to the next and expect TuxOnIce to keep working, and it
doesn't always do that because of changes to the vanilla code that
require an updated patch.
> I really wouldn't consider teaming with Rafael to work on "swsuspOnTux"
> (evolving the in-kernel code while re-using chunks of TuxOnIce code) as
> a bad Plan B. It has the potential of resulting in a solution clearly
> superior to all existing ones (TuxOnIce included).
If there are features in swsusp that TuxOnIce is lacking, or features to
uswsusp that TuxOnIce is lacking, please tell me what they are and I'll
implement them. In saying this, I don't deny that TuxOnIce code can
still be improved - there's a lot I'd still like to do.
to post comments)