Hi. On Sat, 2009-05-09 at 01:05 +0200, Bartlomiej Zolnierkiewicz wrote: > On Friday 08 May 2009 23:59:31 Nigel Cunningham wrote: > > 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...). > > With all respect to sl*b developers but things such as sl*b etc. are on > whole different level when it comes to complexity because their interactions > with weird hardware configurations are quite limited. No, it's apples with apples. The hibernation code we're talking about doesn't do "interactions with weird hardware configurations". It does the job of preparing a hibernation image, compressing and writing that image to disk, showing the user what's going on and doing the reverse at resume time. > > > 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. > > OK. What is exactly your plan for transition and for swsusp removal then? 1) Add the TuxOnIce patches given and enable the compile time option for replacing swsusp by default for a couple of releases. 2) If people find problems, tell them to try using swsusp (echo 0 > /sys/power/tuxonice/replace_swsusp and then try hibernating) and seek the cause of the regression. 3) Once we're satisfied that there are no regressions or they're fixed, prepare code to remove swsusp. > > 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 mean [u]swsusp -> TuxOnIce regressions. I know. I think I dealt with that above. > > > 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. > > Instead of new features I would rather see more effort being put into making > the _core_ TuxOnIce (I mean patch #8 here) smaller (8 KLOC is still a lot, > just to put things into the right perspective the current in-kernel content > of kernel/power/ is 5.5 KLOC) and with more documentation inside the code. Yeah, but those 2.5k extra lines get you more reliability and extra functionality. They're not fat. Regarding documentation - yes, I could put more in the code. That's an area I want to improve too. I don't think, however, that it should be considered a barrier to merging the code into vanilla now. Nigel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
