lkml.org 
[lkml]   [2007]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)


    On Tue, 24 Apr 2007, Pavel Machek wrote:
    > >
    > > If the code just moved somewhere else, it's not "less code".
    >
    > It is not "just moved". It is in userspace, where we can use liblzf /
    > gcrypt / ( and vbetool for s2ram/s2both) as libraries. We have about
    > 7000 LoC of userland code (that is not libraries).

    If it's in user land, we also have

    - communication difficulties between two parts, and all the *crap* that
    tends to entail (ie legacy interfaces forever, and upgrading one
    without the other etc)

    - people who work on the kernel part are working "blind" (ie they are at
    the mercy of whatever userland does, and it's not a "contained"
    subsystem). This just ends up becoming worse when you then interact
    with ten different versions of the user-land stuff, thanks to small
    tweaks by five different vendors, and a hundred random people.

    And don't tell me that doesn't happen. Maybe it doesn't happen _now_,
    because people who use it all get the patches from one place, but the
    moment we start talking about integration into the standard kernel, that
    means that the kernel needs to work regardless of whether somebody uses
    SuSE, RH, Fedora, Ubuntu or cooked his own distro entirely using some
    development version of the suspend user-space tools.

    This is why I don't believe in the whole kernel-line-counting thing. I'm
    personally 100% convinced that it's better to have ten times as many lines
    in the kernel, if it means that you can just forget about version skew and
    bad user-space interfaces etc.

    So if you want to enumerate "good" points, you'd damn well also face the
    _problems_.

    This is why there's a lot to be said for

    echo mem > /sys/power/state

    and being able to follow the path through _one_ object (the kernel) over
    trying to figure out the interaction between many different parts with
    different versions.

    > I believe uswsusp user/kernel separation is clean enough. Kernel
    > provides "snapshot image" and "resume image". (Thanks go to Rafael for
    > very clean interface).

    Now, *that* is the kind of argument that matters.

    Quite frankly, if you want to convince me, it's not by "lines of kernel
    code", but by talking about easy-to-understand interfaces that actuually
    do one thing and do it well (and by "one thing", I mean "one _whole_
    thing"). Because I care a lot less about lines of code than about
    "maintainable interfaces that people can think about and debug".

    I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the
    whole thing. I think they've _all_ caused problems for the "true" suspend
    (suspend-to-ram), and the last thing I want to see is three or four
    different suspend-to-disk implementations. So unlike Ingo, I don't think
    "let's just integrate them all side-by-side and maintain them and look who
    wins" is really a good idea.

    How many different magic ioctl's does the thing introduce? Is it really
    just *two* entry-points (and how simple are they, interface-wise), and
    nothing else?

    Linus
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-25 01:45    [W:4.677 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site