[lkml]   [2007]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
    Rafael J. Wysocki wrote:
    > On Friday, 13 July 2007 19:32, Huang, Ying wrote:
    > > On Thu, 2007-07-12 at 20:06 -0700, wrote:
    > > > >> I agree, a stipped down hibernate kernel can be very small, not
    > > > >> allocating this memory until it's needed is a step for the final
    > > > >> polishing.
    > > > >
    > > > > I'm not sure if I agree with that. In any case, having to use two
    > > > > different kernels for hibernation would be a big drawback.
    > > >
    > > > I see it as a big advantage to not have to use the main kernel for the
    > > > suspend. please keep it as an option at least.
    > >
    > > Yes. It has additional bonus to make it possible to write/read image
    > > from a program other than main kernel. For example, for a specific
    > > mobile device product (Such as Intel MID), a customized ultra-small
    > > program (or kernel) can be composed to write/read image. That way, the
    > > hibernate/resume time can be reduced to minimal.

    Sounds great!

    > You don't need kexec for that. This is how the userland hibernation (aka
    > uswsusp) works.

    I don't think so. uswsusp runs under the normal kernel which implies an
    interdependency, whereas a device driver stub'd with a small single proc
    kernel would run in its own space.

    The question is, how small could this kernel stub be made and still leverage
    the device driver pool?



    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-07-13 17:33    [W:0.022 / U:47.884 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site