lkml.org 
[lkml]   [2009]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [TuxOnIce-devel] [RFC] TuxOnIce
    Date
    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.

    > > 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?

    > 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 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.

    Thanks,
    Bart


    \
     
     \ /
      Last update: 2009-05-09 01:05    [W:4.120 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site