Hi,
Summary: Add missing include guards for some x86 headers.
This has only had the most rudimentary testing, but is hopefully obviously

correct. (That's just doomed to generate some sort of build failure, isn't

it?)
Thanks.
Vegard
PS: I now have a pretty cool framework in Perl for parsing and checking

headers. And it can be used to transform them automatically too. So if you

want to standardize the guard format of all the headers in one go, we have

the means to do it quickly and efficiently...
diff --git a/include/asm-x86/seccomp_64.h b/include/asm-x86/seccomp_64.h

index 553af65..76cfe69 100644

--- a/include/asm-x86/seccomp_64.h

+++ b/include/asm-x86/seccomp_64.h

@@ -1,4 +1,5 @@

 #ifndef _ASM_SECCOMP_H

+#define _ASM_SECCOMP_H
 #include <linux/thread_info.h>
diff --git a/include/asm-x86/suspend_32.h b/include/asm-x86/suspend_32.h

index 24e1c08..8675c67 100644

--- a/include/asm-x86/suspend_32.h

+++ b/include/asm-x86/suspend_32.h

@@ -3,6 +3,9 @@

  * Based on code

  * Copyright 2001 Patrick Mochel <mochel@osdl.org>

  */

+#ifndef __ASM_X86_32_SUSPEND_H

+#define __ASM_X86_32_SUSPEND_H

+

 #include <asm/desc.h>

 #include <asm/i387.h>
@@ -44,3 +47,5 @@ static inline void acpi_save_register_state(unsigned long return_point)

 /* routines for saving/restoring kernel state */

 extern int acpi_save_state_mem(void);

 #endif

+

+#endif /* __ASM_X86_32_SUSPEND_H */

diff --git a/include/asm-x86/xor_32.h b/include/asm-x86/xor_32.h

index 067b5c1..921b458 100644

--- a/include/asm-x86/xor_32.h

+++ b/include/asm-x86/xor_32.h

@@ -1,3 +1,6 @@

+#ifndef ASM_X86__XOR_32_H

+#define ASM_X86__XOR_32_H

+

 /*

  * Optimized RAID-5 checksumming functions for MMX and SSE.

  *

@@ -881,3 +884,5 @@ do {							\

    deals with a load to a line that is being prefetched.  */

 #define XOR_SELECT_TEMPLATE(FASTEST)			\

 	(cpu_has_xmm ? &xor_block_pIII_sse : FASTEST)

+

+#endif /* ASM_X86__XOR_32_H */

diff --git a/include/asm-x86/xor_64.h b/include/asm-...
[ message continues ]

very nice! I think the reference should be something like the unified

include/asm-x86/processor.h.
could you try a run with that and put the result into a git tree for me

to pull for review? I think we want to finetune that result and do a

flag day for those cleanups, right after all the x86 topics went into

v2.6.27.
	Ingo

--

Done! You can pull the 'for-x86' branch of
    git pull git://git.kernel.org/pub/scm/linux/kernel/git/vegard/linux-2.6-headers.git

for-x86
(that's gonna wrap.) The first commit

(d160e5c4f1b912ec7c1583c393bb3db66cdb63c2) is the interesting one, the

rest are just manual fix-ups.
I've looked over most of it to make sure everything's okay; in

addition, the diff consists of change in preprocessor lines only.

'make headers_check' also succeeds, although no change here should

change the result of that.
The headers that still need to be looked at manually (probably because

there was no guard there in the first place), are:
# add include/asm-x86/mach-visws/entry_arch.h

# add include/asm-x86/mach-visws/setup_arch.h

# add include/asm-x86/mach-visws/smpboot_hooks.h

# add include/asm-x86/posix_types.h

# add include/asm-x86/mach-default/pci-functions.h

# add include/asm-x86/mach-default/entry_arch.h

# add include/asm-x86/mach-default/do_timer.h

# add include/asm-x86/mach-default/smpboot_hooks.h

# add include/asm-x86/vic.h

# add include/asm-x86/suspend_32.h

# add include/asm-x86/calling.h

# add include/asm-x86/alternative-asm.h

# add include/asm-x86/processor-cyrix.h

# add include/asm-x86/mach-voyager/entry_arch.h

# add include/asm-x86/mach-voyager/do_timer.h

# add include/asm-x86/mach-voyager/setup_arch.h

# add include/asm-x86/mach-rdc321x/rdc321x_defs.h

# add include/asm-x86/unistd.h

# add include/asm-x86/irqflags.h

# add include/asm-x86/vmi.h

# add include/asm-x86/voyager.h

# add include/asm-x86/frame.h
Vegard (a.k.a. "The Churninator")
--

"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

--

thanks Vegard, these changes are looking rather good. I've created a

tip/x86/header-guards topic for it and did a test-merge. There were 30+

trivial conflicts with tip/master that were easy to fix - find the list

of conflicting files below.
Lets keep these changes out of tip/master for now though, to reduce the

churn - i'll do a merge/rebase in the v2.6.27-rc1 timeframe, ok?
or perhaps we could include it in tip/master right now as well, if you

did another branch that excluded the files below. That would make

merging a lot easier - and we could do a second phase in v2.6.27-rc1.

Hm?
	Ingo
-------------------->

commit c4f439ec18082153bcff1bd6e4550dbad5ff5cbc

Merge: efd27e7... 391ebbd...

Author: Ingo Molnar <mingo@elte.hu>

Date:   Thu Jun 26 13:55:09 2008 +0200
    Merge branch 'x86/header-guards'
    Conflicts:
    	include/asm-x86/bios_ebda.h

    	include/asm-x86/bootparam.h

    	include/asm-x86/current_32.h

    	include/asm-x86/current_64.h

    	include/asm-x86/ds.h

    	include/asm-x86/e820_32.h

    	include/asm-x86/e820_64.h

    	include/asm-x86/fixmap.h

    	include/asm-x86/fixmap_64.h

    	include/asm-x86/gart.h

    	include/asm-x86/genapic_64.h

    	include/asm-x86/hw_irq_32.h

    	include/asm-x86/hw_irq_64.h

    	include/asm-x86/i8259.h

    	include/asm-x86/irq_32.h

    	include/asm-x86/irq_64.h

    	include/asm-x86/kdebug.h

    	include/asm-x86/mach-bigsmp/mach_mpspec.h

    	include/asm-x86/mach-default/irq_vectors.h

    	include/asm-x86/mach-default/irq_vectors_limits.h

    	include/asm-x86/mach-es7000/mach_mpspec.h

    	include/asm-x86/mach-numaq/mach_mpspec.h

    	include/asm-x86/mach-summit/mach_mpspec.h

    	include/asm-x86/mach-visws/irq_vectors.h

    	include/asm-x86/mach-voyager/irq_vectors.h

    	include/asm-x86/pat.h

    	include/asm-x86/percpu.h

    	include/asm-x86/processor-flags.h

    	include/asm-x86/seccomp_32.h

    	include/asm-x86/seccomp_64.h

    	include/asm-x86/thread_info.h

    	include/asm-x86/...
[ message continues ]

Hi,
I don't think we really need to resolve conflicts at all. What we can

do is simply to re-run the scripts against tip/master whenever you

want the update.
I have created a 'for-tip' branch at

git://git.kernel.org/pub/scm/linux/kernel/git/vegard/linux-2.6-headers.git

which is a re-run against the most recent tip/master. (The previous

link was against something rather old like -rc6.)
I am not sure this is what you wanted. In either case, re-running is

not a problem, and neither is excluding a set of files. Please do this

with as little pain for yourself as possible. The purpose of the

script is to avoid manual work.
Also, by the way: Can -tip now be cloned with --shared to save space

as long as I only have branches with references to commits in

tip/master? Or is this still to be considered unsafe?
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

--

it's unsafe if we ever rewind a commit that you rely on later, and

git-gc zaps it from tip.git?
i think it would be better to not rely on that yet. The overwhelming

majority of activities in tip.git are append-only, but the integration

branches (which are included in tip/master) get regenerated frequently.

If you base on a topic branch itself (say tip/x86/nmi) - that should be

pretty stable.
	Ingo

--

... the right moment for this would be about now. Mind rerunning your

scripts and create a pullable linux-2.6-headers tree, based on latest

-git?
	Ingo

--

Aright! Here she is; you may pull the 'for-tip' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/vegard/linux-2.6-headers.git

for-tip
To see the result. This was based on tip/master. Shortlog:
Vegard Nossum (3):

      x86: consolidate header guards

      kvm: fix spurious '#' in header

      kvm: consolidate header guard
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

--

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.
	Ingo

--

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.
	Ingo

--

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

--

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

--

I've updated my script to also fix any rogue uses of header-guard names in

auxiliary files. I'm attaching the resulting patch.
It doesn't really _fix_ the hideous hack, it merely unbreaks it.
Patch #2 also fixes some left-over headers. They both apply on top of

tip/x86/header-guards.
(I guess it should be tested for a bit longer before going to linux-next,

just in case something else bad happens? I did a small test on x86_32 and

x86_64, and also verified that UML doesn't require any of the x86 header

guard names.)
Thanks,
Vegard
From 3ec9258ef7414d3dd0a8a6c399bd2cd58103bf62 Mon Sep 17 00:00:00 2001

From: Vegard Nossum <vegard.nossum@gmail.com>

Date: Tue, 22 Jul 2008 13:53:24 +0200

Subject: [PATCH] x86: fix other files that depend on specific header-guard names
This patch should be squashed into the first "consolidate header guards"

commit in order to preserve bisectability.
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>

---

 arch/x86/boot/compressed/misc.c  |    2 +-

 arch/x86/kernel/asm-offsets_64.c |    2 +-

 arch/x86/kernel/syscall_64.c     |    4 ++--

 3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c

index bc5553b..3ee338c 100644

--- a/arch/x86/boot/compressed/misc.c

+++ b/arch/x86/boot/compressed/misc.c

@@ -16,7 +16,7 @@

  */

 #undef CONFIG_PARAVIRT

 #ifdef CONFIG_X86_32

-#define _ASM_DESC_H_ 1

+#define ASM_X86__DESC_H 1

 #endif
 #ifdef CONFIG_X86_64

diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c

index bacf5de..a39b19a 100644

--- a/arch/x86/kernel/asm-offsets_64.c

+++ b/arch/x86/kernel/asm-offsets_64.c

@@ -20,7 +20,7 @@
 #define __NO_STUBS 1

 #undef __SYSCALL

-#undef _ASM_X86_64_UNISTD_H_

+#undef ASM_X86__UNISTD_64_H

 #define __SYSCALL(nr, sym) [nr] = 1,

 static char syscalls[] = {

 #include <asm/unistd.h>

diff --git a/arch/x86/kernel/syscall_64.c b/arch/x86/kernel/syscall_64.c

index 170d43c..3d...
[ message continues ]

looks good - do you have a branch i could pull into

tip/x86/header-guards?
	Ingo

--

I've pushed it to the 'for-tip' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/vegard/linux-2.6-headers.git
(Note that since you rebased the same branch last time, I just applied

my patches on top of _your_ branch and pushed that to above location.)
Though I still believe it should be squashed for bisectability.
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

--

hm, i pulled it but 1ab9e368 cannot be squashed into aa27f9586 cleanly.
I'd suggest the following approach, which we used for the scripted

unification of arch/x86. Do a couple of preparatory patches that just

bring all the header guards into proper shape. _Then_ run the script

against that "prepared" tree. The end result should be correct to the

best of our current knowledge. (i'll figure out any remaining build

breakages quickly - i can build 120+ random kernels per hour)
We can rebase x86/header-guards to such a bisectable approach no problem

if you can do it like that, it's not yet merged anywhere. Just send me a

pull URI that i'll pull into a x86/header-guards that is reset back to

linus/master.
Can you see any complications with that approach?
	Ingo

--

There's not really that much to prepare. But it really helps to work

against the right tree to begin with :-)
So here's another one, this time prepared against linus/master, and

fully bisectable by delaying the fixing of the headers which have

external users of their guard-names. Check out the (new) 'for-tip'

branch of
    git://git.kernel.org/pub/scm/linux/kernel/git/vegard/linux-2.6-headers.git
There are still headers left which have no guard at all; that's okay.

If they should be changed, it can be done later, it shouldn't make a

difference for now.
Thanks :-)
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

--

pulled into tip/x86/header-guards, thanks Vegard.
One small request: in the future, could you use git-request-pull to

generate pull requests?
That way the full URI is included (otherwise it's easy to forget to add

the 'for-tip' branch to the pull i do, etc.). Something like:
 git-request-pull linus/master \

  git://git.kernel.org/pub/scm/linux/kernel/git/vegard/linux-2.6-headers.git \

   for-tip
should do the trick. Thanks,
	Ingo

--

Hi Vegard.
Can I ask you to chase all uses of #include <asm-x86/xxx.h>

and convert them to #include <asm/xxx.h>
When we move include/asm-x86 to arch/x86/include/asm this is needed and

better to fix these sooner.
	Sam
--

Hm. I can't really seem to find many:
./Documentation/lguest/lguest.c:#include "asm-x86/bootparam.h"

./arch/um/sys-x86_64/syscall_table.c:#include <asm-x86/unistd_64.h>

./arch/um/sys-x86_64/syscall_table.c:#include <asm-x86/unistd_64.h>

./arch/ia64/ia32/audit.c:#include <asm-x86/unistd_32.h>
..and I don't even know how to fix them. It seems that we might want

to use filesystem links here instead? (Git should be able to handle

that.)
E.g. so that arch/ia64/include/asm/unistd_32.h ->

arch/x86/include/asm/unistd_32.h. Then arch/ia64/ia32/audit.c can

#include <asm/unistd_32.h>.
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

--

Looking at the list again you are right that this is not the type of

'bugs' that I initially thought it was.

We should leave them as is for now and fix it up when

It is better to be explicit in the include than trying to do clever

tricks behind the bag og gcc.
	Sam

--