Re: i386-arch-cleanup-seralize-msr-fix.patch added to -mm tree

From: Zachary Amsden
Date: Sun Jul 31 2005 - 14:58:49 EST

akpm@xxxxxxxx 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.


(*) 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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at