Re: [git pull] x86 updates for v2.6.28, phase #1

[Ingo Molnar <mingo@elte.hu>]

* Vegard Nossum <vegard.nossum@gmail.com> wrote:

> On Fri, Oct 10, 2008 at 5:58 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Ingo Molnar <mingo@elte.hu> wrote:
> >
> >> > Ok, so I pulled phase 1, but quite frankly, I think this was utter
> >> > crap. Why the hell did this go in?
> >>
> >> we'll fix that up. We'll move all header files to
> >> arch/x86/include/asm/ anyway later in the merge window, once the dust
> >> settles, and can do a separate commit for this as well.
> >
> > we'll do the commit below once we've moved the header files to
> > arch/x86/include/asm/. (doing it right now would conflict with various
> > existing branches so it would be nice to wait with this.)
> >
> >        Ingo
> >
> > ---------------->
> > From 5f3a8db0d4b091521541153580454099618fec2c Mon Sep 17 00:00:00 2001
> > From: Ingo Molnar <mingo@elte.hu>
> > Date: Fri, 10 Oct 2008 17:51:28 +0200
> > Subject: [PATCH] x86: fix header guard naming ugliness
> >
> > as Linus has noticed, the underscore aspect of these changes in
> > 77ef50a ("x86: consolidate header guards") are bogus:
> >
> > -#ifndef _ASM_BOOT_H
> > -#define _ASM_BOOT_H
> > +#ifndef ASM_X86__BOOT_H
> > +#define ASM_X86__BOOT_H
> >
> > as Linus pointed out:
> >
> > 1) header guard symbols are internal symbols in a reserved namespace,
> >   so a leading underscore is perfectly justified
> >
> > 2) user-space might accidentally stumble into the new symbols:
> >
> >        #include <sys/types.h>
> >
> >        int ASM_X86__TYPES_H = 1;
> >
> > plus this deviates from all the standard header guard naming we
> > use elsewhere in the kernel.
> 
> Note: If you don't want the double underscores anywhere, this patch is
> not enough.

yeah - it was just a simple sed job.

> For example:
> 
> > -#endif /* ASM_X86__MACH_DEFAULT__MACH_TIMER_H */
> > +#endif /* _ASM_X86_MACH_DEFAULT__MACH_TIMER_H */
> 
> There are also a few non-trivial changes, which could break with a 
> naïve sed script. So I suggest to simply revert it, it's a lot safer 
> than trying to patch it up in the last minute.
> 
> I'm obviously also sorry for causing this problem in the first 
> place... *blush*

it's not your fault really, you clearly suggested multiple variants and 
asked our opinion and we accepted that approach. So the buck stops here 
:)

	Ingo