lkml.org 
[lkml]   [2006]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: 2.6.17-rc1-mm1: KEXEC became SMP-only
    From
    Date
    Zachary Amsden <zach@vmware.com> writes:

    > No, this cleanup only eliminates the need to duplicate redundant code. How
    > does a machine vector make it any harder to break? You still have a function
    > with multiple definitions. Duplicating code makes things really easy to break -
    > twice.

    Sharing functions is good, but if you don't share things carefully your code
    becomes very brittle because it depends in non obvious ways on other
    code.

    A machine vector isn't exactly what is needed (although that allows building
    all of the subarches at the same time). What is needed are clear places
    where the sub architectures get called.

    The lack of visibility is what makes subarch code so easy to break right now.

    I have had times where I have made a global change and fixed up the entire
    kernel and all that broke was the i386 subarchitectures because there
    was a dependency but it was totally invisible. Despite testing on and
    being most familiar with i386.

    For example every other arch only has one implementation
    of machine_restart, machine_halt, machine_power_off, and if they
    have subarchitectures they have calls to subarch_restart, subarch_halt,
    and subarch_power_off. At which point it is trivial to see that
    the code lives in a subarchitecture.

    Even if that code turns right around and calls a common function on
    all but one of the subarchitectures, at least the logic is visible when
    you read the code.

    If all you are doing is this one little clean up we can probably stop here.
    But this looks like a start on getting a vmi or xen subarch working.

    If this is really a prelude to introducing more subarchitectures we
    need to fix the infrastructure, so it is obvious what is going on.
    I would really like to see a machine vector, so we could compile in
    multiple subarchitectures at the same time. That makes building
    a generic kernel easier, and the requirement that the we need
    to build a generic kernel makes the structure of the subarchiteture
    hooks hierarchical and you wind up with code whose dependencies
    are visible. Instead of the current linker and preprocessor magic.
    Functions named hook are impossible to comprehend what they
    are supposed to do while reading through the code.

    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: 2006-04-04 20:46    [W:4.157 / U:0.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site