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

[Zachary Amsden <zach@vmware.com>]

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.