[lkml]   [2004]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Suspend 2 merge

    Nigel Cunningham wrote:

    > On Mon, 2004-11-29 at 20:34, Stefan Seyfried wrote:

    >>and not everyone who downloads suspend2 uses it ;-)
    > Yes... I'd say the relative percentage would be much higher, though.

    you are probably right here :-)

    >>>change a parameter or forcing them to do an ls in /dev with obscure
    >>>parameters (to get the major and minor numbers) when they already know
    >>>they want /dev/sda1 isn't user friendly. Obviously user friendliness is
    >>This can easily be done by a userspace helper. You do use the
    >>(userspace) X server to display your GUI, don't you?
    > No. Not at all. All of userspace is well and truly wedged in a block of
    > ice by then.

    you are not changing the suspend device after freezing userspace, or i
    am getting something horribly wrong here.

    so if you have 2 choices of an interface:
    1) more complex kernel code, but you can do "echo /dev/name > /proc/foo"
    2) less complex kernel code, now you have a userspace helper e.g.
    "suspend_ctl foodev /dev/name" which then does the magic number
    calculations in userspace and puts the magic number into the kernel.

    I think that interface 2) would be preferred by most kernel developers.
    Especially since this is code only needed on a relatively small subset
    of all linux installations.

    There is a "top" userspace program to parse kernel numbers, we don't
    have "/proc/top".

    >>Putting only the absolutely necessary things into the kernel (the same
    >>is true for the interactive resume thing - if someone wants interactive
    >>startup at a failing resume, he has to use an initrd, i don't see a
    >>problem with that) will probably increase the acceptance a bit :-)
    > That's fine if your initrd is properly configured and you're willing to

    This is something distributions have to take care of.

    > add extra cruft to the kernel so userspace can get the info it needs,

    not much extra cruft is needed. The "echo resume > /sys/power/state"
    just returns (which it wouldn't if the resume was successful), then you
    can decide what to do next.

    > and report what the user wants to do. If, however, you don't use an
    > initrd, you're sunk.

    yes. There are other prerequisites for suspend than using an initrd
    though (you need a computer :-). If you don't use an initrd, you cannot
    use the interactive features but have to decide at compile time which
    way to go if the resume fails. That's life.

    > Regarding acceptance, there's no point in getting it accepted into the
    > kernel if we end up with something that's user-unfriendly. I think it
    > will help a lot if we agree that suspend does need to blur the lines
    > between kernel and userspace a little, in the interests of providing
    > software that is superior.

    User-friendlyness is an joint effort of kernel and userspace. The user
    does not care who does the work when he clicks on his "hibernation" Icon
    in the taskbar. (The same is true for users of an hibernation script).
    Actually, the thing that makes suspend2 more reliable than swsusp is
    probably the very good hibernation script (userspace) that saves users
    the reading of documentation since it automatically unloads all critical
    modules etc. For me, pavel's later versions as in SUSE 9.2 have worked
    out of the box on every non-SMP i386 notebook i have laid my hands on in
    the last 6 months (thanks to userspace taking care of bad modules etc).


    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: 2005-03-22 14:08    [W:0.023 / U:102.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site