[email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |