lkml.org 
[lkml]   [2006]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]
    Date
    Hi.

    On Saturday 08 July 2006 10:28, Pavel Machek wrote:
    > I really looked at suspend2 hard, year or so ago, when I was pretty
    > tired of the flamewars. At that point I decided it is way too big to
    > be acceptable to mainline, and got that crazy idea about uswsusp, that
    > surprisingly worked out at the end.
    >
    > uswsusp makes suspend2 obsolete, and suspend2 now looks
    > misdesigned. It puts too much stuff into the kernel, you know that
    > already.

    No, I don't. From my point of view, uswsusp is misdesigned, but suspend2
    isn't. Suspend2 keeps the stuff that ought to be done by the kernel in the
    kernel. It doesn't shift data out to userspace, only to copy it straight back
    to the kernel for I/O. It will keep working even if userspace crashes and
    burns. It leverages support for compression and encryption that's already in
    the kernel. It does a real image of memory, not a half-pie attempt that
    causes lots of faulting of pages etc post-resume. If there's any misdesign in
    Suspend2, it's that I haven't made it a special case of checkpointing. But,
    of course, there's no support for checkpointing in the rest of the kernel at
    the moment anyway.

    > From your point of view, uswsusp is misdesigned, too. It is too damn
    > hard to install. There's no way it could survive as a standalone patch
    > -- the way suspend2 survives. Fortunately, from distro point of view,
    > being hard to install does not matter that much. Distros already have
    > their own initrds, etc. And in the long term, distros matter, and I'm
    > quite confident I can make 90% distributions ship uswsusp + its
    > userland; cleaner kernel code matters, too, and maybe you'll agree
    > that if you only look at the kernel parts, uswsusp looks nicer.

    It looks simple, I agree. But that's only because it's doing the minimum
    required.

    > Now, you are asking me to review 14000 lines of code. That's quite a
    > lot of code, and you did not exactly make reviewer's life easy. Also
    > reviews usually stop at first "fatal" problem, and you still drive
    > user interface from kernel. (Yes, drawing is done in userland, but
    > core user interface code is still in kernel). That is "fatal".

    I agree that I didn't do the best job of making the reviewer's life easy. But
    let's give me some credit. I did all those patches because I genuinely
    thought that's what was requested the last time I submitted patches for
    review. I didn't like splitting up the files into all those patches - it was
    a lot of work and took a lot of time. But I did it because I wanted to do
    what was asked and wanted to do what was necessary to get a good
    implementation into the vanilla kernel.

    Frankly, I'd rather be working on improving drivers and helping implement the
    run-time power management than working on getting Suspend2 merged. But for
    now, this is the immediate task.

    I don't know why you see the user interface code as a problem. All the kernel
    is doing is telling the userspace program, via a netlink socket, what's going
    on and receiving messages from the userspace program sometimes.

    > (Greg mentioned /proc usage being "fatal", too).

    > Now... moving user interface into userland, and removing /proc usage
    > are big tasks, do you agree? And they will mean lot of changes, and
    > lot of new testing.

    Removing /proc isn't a big task. It will affect the hibernate script far more
    that the kernel code. The user interface is already in userland.

    > Perhaps at this point right solution is to just drop suspend2
    > codebase, and do it again, this time in userland? Kernel
    > infrastructure is already there, and even if you wanted to replace
    > [u]swsusp by suspend2, you have to understand how the old code
    > works. (Another point you may like is that forking suspend.sf.net code
    > is relatively easy; so even if we disagree about coding style of the
    > userland parts, I can't veto it or something. And given that your only
    > problem is including all the possible features, I probably will not
    > have reason to stop you or something -- having all the features is
    > okay in userland).

    I don't want to fork anything. I didn't fork swsusp to start with, and I don't
    want to start forking things now. (If you want to debate that point, can you
    check the mailing list archives on Sourceforge, Berlios and suspend2.net
    first? You'll find that I just carried on where Florent left off).

    > Now... switching to uswsusp kernel parts will make it slightly harder
    > to install in the short term (messing with initrd). OTOH there's at
    > least _chance_ to get to the point where suspend "just works" in
    > Linux, in the long term...
    >
    > (Of course, you can just ignore this and keep maintaining out-of-tree
    > suspend2. We'll also get to the point where it "just works"... it will
    > just take a little longer.)

    With your current design, I don't see how you're ever going to get to the
    level of functionality that Suspend2 has. I'm of course thinking of a full
    image of memory (although Rafael's patch a while back looked hopeful there)
    and support for other-than-just-one-swap-partition.

    Regards,

    Nigel
    --
    Nigel, Michelle and Alisdair Cunningham
    5 Mitchell Street
    Cobden 3266
    Victoria, Australia
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2006-07-08 05:47    [W:3.994 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site