Hi. 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. Regards, Nigel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
