lkml.org 
[lkml]   [2005]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: -mm -> 2.6.13 merge status


    --Andrew Morton <akpm@osdl.org> wrote (on Tuesday, June 21, 2005 14:04:41 -0700):

    > Gerrit Huizenga <gh@us.ibm.com> wrote:
    >>
    >> Kexec/kdump has a chance of working reliably.
    >
    > IOW: Kexec/kdump has a chance of not working reliably.
    >
    > Worried.

    Personally I'm more concerned about the design issues - I can't see how
    any of the other options are sustainable / workable. Things that require
    maintaining their own driver base are just insane. Things that dump from
    the panicing kernel are just broken. People want to be able to dump to
    disk / network / flash-ram card / god-knows-what, so we need something
    that's flexible.

    I don't think kdump is perfect and bug-free yet, but at least it has a
    design that looks like it'll be workable and sustainable through the future.
    Plus it's a small patch on top of kexec, which is useful in it's own right
    (for fast reboot, etc) so we get to reuse a lot of code.

    We could go into how crashdump itself is important (eg. first time failure
    capture is critical for customers, less downtime, I can ship you better
    data on bugs I find in test, etc, etc) but I kind of assumed most people
    were convinced of that by now. Even Linus seemed to think kdump was the
    sensible way forward (at KS last year), and he seems to be one of the
    most ardent sceptics of crashdump I've ever met ;-)

    M.

    -
    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: 2005-06-22 10:19    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean