lkml.org 
[lkml]   [2002]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [lkcd-devel] Re: What's left over.
    From
    Date
    Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

    > On Tue, 2002-11-05 at 18:00, Werner Almesberger wrote:
    > > Yes, I've just checked with Eric, and he hasn't received any
    > > indication from Linus so far. I posted a reminder to linux-kernel.
    > > I'd really hate to see kexec miss 2.6.
    >
    > Let me ask the same dumb question - what does kexec need that a dumper
    > doesn't. In other words given reboot/trap hooks can kexec happily live
    > as a standalone module ?

    In replying to another post by Al Viro I managed to think this through.
    kexec needs:

    - An allocated slot in some namespace.
    - The ability to request the kernel devices shut themselves down.
    - Buffers that are safe to use.
    - The ability to transition the cpu into a state that is suitable
    for jumping to another kernel.
    - Awareness of it's existence.

    Most of this code is intimate with how the kernel currently behaves
    and needs at least minor adjustments for things like living in PAE
    mode.

    The safe buffers a kernel can probably avoid.

    I cannot see the core functionality of kexec every living happily as a
    standalone module. The kexec code accomplishes nothing. If there is
    something useful it does it can probably be moved elsewhere and the
    line count reduced. The entire code base is basically obsessed with
    getting safe temporary buffers for the new kernel to live in, and
    given improvements to how the kernel allocates memory that are
    theoretically possible with rmap I could remove that code as well.

    The only thing that keeps kexec at all maintainable outside the kernel
    is that big fundamental changes do not happen often. But the kernel
    must be tracked, closely. I don't see that as a recipe for a
    standalone module. I can barely even see making the code a module, or
    what the point would be.

    The reason kmonte fails in so many cases where kexec succeeds is
    precisely because kmonte is a module.

    If we include machine_kexec or something very similar to but more
    generalized to the list of exported functions, perhaps kexec could
    just have the buffer allocation code and live happily outside of the
    kernel. But as it is, if we want to factor kexec into pieces so one
    piece can live happily as a standalone module it will take some
    serious design work, and a total rethink of the implementation. And
    we will still have to add code to the kernel.

    Eric
    -
    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-03-22 13:30    [W:6.544 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site