Re: [PATCH] x86: more header fixes

[Vegard Nossum]

On Wed, Jul 16, 2008 at 3:17 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
>
> * Ingo Molnar <mingo@xxxxxxx> 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.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/