lkml.org 
[lkml]   [2005]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: i386-arch-cleanup-seralize-msr-fix.patch added to -mm tree
    akpm@osdl.org wrote:

    >The patch titled
    >
    > i386-arch-cleanup-seralize-msr fix
    >
    >diff -puN arch/i386/kernel/microcode.c~i386-arch-cleanup-seralize-msr-fix arch/i386/kernel/microcode.c
    >--- 25/arch/i386/kernel/microcode.c~i386-arch-cleanup-seralize-msr-fix 2005-07-30 23:40:17.000000000 -0700
    >+++ 25-akpm/arch/i386/kernel/microcode.c 2005-07-30 23:40:34.000000000 -0700
    >@@ -83,6 +83,7 @@
    > #include <asm/msr.h>
    > #include <asm/uaccess.h>
    > #include <asm/processor.h>
    >+#include <asm/processor.h>
    >


    Sorry to break something yet again. Looks like a duplicate include got
    inserted here. Actually this last fix brings up a very valid point.
    There is now sharing in both directions between i386 and x86_64 (I was
    only aware that early_printk.c was shared from the x86_64 tree). There
    is still a lot more code that could be shared; in particular, one can
    only imagine how many apic and io-apic bugs have been caused or are
    still lurking because of lack of shared code (*). A lot of these code
    cleanups I submitted could be utilized by x86_64 as well, and if we
    continue to move machine specific inline assembler into header files and
    out of the arch directory, there is a lot more chance to share code -
    even across entirely different architectures, as eventually happened to
    much of irq.c.

    Is it worthwhile considering some more explicit way of sharing code
    between i386 and x86_64? I don't like breaking builds for one or the
    other because I changed a file that I did not know was shared, and it is
    not always possible to personally test both builds from every location I
    might be at. I think moving x86_64 as a sub-arch of i386 is rather far
    too radical, for now, but perhaps there is a better solution
    (arch/i386/x86_64-shared/) to make code sharing explicit so that
    developers are always thinking about these issues when changing code here.

    Zach

    (*) It is quite likely the APIC / IO-APIC code would require a minimal
    set of #ifdefs to be shared, because code must deal with different board
    features and vendors, but the ugliness of a couple of #ifdefs combined
    with strategic creation of machine specific abstractions via header
    files could likely win huge savings by increasing the number of people
    testing and debugging common code.
    -
    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-07-31 22:00    [W:3.041 / U:0.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site