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

    * Linus Torvalds <> wrote:

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

    userspace-driven-suspend is already in the kernel, today. So it's not
    really "two versions side by side doing the same thing", but more of:

    A B C + D E F G H

    where "ABC" is used by the uswsusp code today, and "ABCDEFGH" is used by
    suspend2. So any "suspend2 merge" would largely be about adding "DEFGH".
    (uswsusp of course redoes 'DEFGH' in user-space its own way, and there
    is the inevitable "+" glue code as well, but it's at least not two
    parallel versions of the same thing in the kernel, which would be

    My original mail was about the following thing: i tried the suspend2
    patch (which just makes "echo disk > /sys/power/state" work as expected,
    as long as you give the booting up kernel image an idea about where the
    swap partition we suspended to is, via a single boot option) and that it
    was pretty straightforward and worked well, and that i think its way of
    reusing the existing suspend infrastructure and doing the add-ons
    cleanly while keeping the existing user-hibernate code intact looked
    viable to me.

    I.e. to me it looked like while there are apparent conflicts of
    personalities suspend2 did not really seem to be a hostile
    reimplementation of 'A B C', but that it tries to build upon 'A B C' and
    just has a different technical opinion about whether 'DEFGH' should be
    in the kernel or outside of it.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-25 08:45    [W:0.024 / U:8.272 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site