Messages in this thread | | | Date | Wed, 16 Jul 2008 16:22:25 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86: more header fixes |
| |
* Vegard Nossum <vegard.nossum@gmail.com> wrote:
> On Wed, Jul 16, 2008 at 3:17 PM, Ingo Molnar <mingo@elte.hu> wrote: > > > > * Ingo Molnar <mingo@elte.hu> wrote: > > > >> thanks. I've picked up these changes and rebased them to -git. (that > >> way they can be maintained as a topic easier) The few files that were > >> left out due to conflicts we can do later on. I pushed the result out > >> into the tip/x86/header-guards topic branch - please double-check that > >> i merged it right. > > > > hm, doesnt work with: > > > > http://redhat.com/~mingo/misc/config-Wed_Jul_16_15_13_24_CEST_2008.bad > > > > include/asm/mpspec.h:39: error: 'MAX_MP_BUSSES' undeclared here (not in > > a function) > > In file included from include/asm/smp.h:15, > > from include/linux/smp.h:28, > > from include/asm/desc.h:8, > > from include/asm/elf.h:89, > > from include/linux/elf.h:7, > > from arch/x86/boot/compressed/misc.c:29: > > include/asm/io_apic.h:149: error: 'MAX_IRQ_SOURCES' undeclared here (not > > in a function) > > > > etc. Some of those header guards confused some other code i guess. > > Yes, you are right. Check out this incredibly hideous hack of > arch/x86/boot/compressed/misc.c: > > /* > * we have to be careful, because no indirections are allowed here, and > * paravirt_ops is a kind of one. As it will only run in baremetal anyway, > * we just keep it from happening > */ > #undef CONFIG_PARAVIRT > #ifdef CONFIG_X86_32 > #define _ASM_DESC_H_ 1 > #endif > > #ifdef CONFIG_X86_64 > #define _LINUX_STRING_H_ 1 > #define __LINUX_BITMAP_H 1 > #endif > > I'm not sure how we should proceed with this. On one hand, we could > just fix the issues as they come up and be done with it. On the other > hand, this was exactly the thing I wanted to avoid by automatic it. I > guess it can never be fully automated... The question is if there is > any danger of *silent* (read: runtime) breakage, which would be much > worse than compiler errors.
dont worry, lets fix the above hideous hack first, then i can merge the guards fixes ontop of that fix. That's why we do testing, to catch the cases where assumptions fail. Your script is just fine - it beats having to edit 280+ files by hand ...
Ingo
| |