[PATCH] x86: more header fixes

[PATCH] x86: more header fixes

[Vegard Nossum]

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-x86/xor_64.h
index 24957e3..2d3a18d 100644
--- a/include/asm-x86/xor_64.h
+++ b/include/asm-x86/xor_64.h
@@ -1,3 +1,6 @@
+#ifndef ASM_X86__XOR_64_H
+#define ASM_X86__XOR_64_H
+
 /*
  * Optimized RAID-5 checksumming functions for MMX and SSE.
  *
@@ -354,3 +357,5 @@ do {						\
    We may also be able to load into the L1 only depending on how the cpu
    deals with a load to a line that is being prefetched.  */
 #define XOR_SELECT_TEMPLATE(FASTEST) (&xor_block_sse)
+
+#endif /* ASM_X86__XOR_64_H */

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

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

> Hi,
> 
> Summary: Add missing include guards for some x86 headers.

applied to tip/x86/cleanups, thanks Vegard.

> 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?)

heh ;-)

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

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

Re: [PATCH] x86: more header fixes

[Vegard Nossum]

On Wed, Jun 18, 2008 at 12:30 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Vegard Nossum <vegard.nossum@gmail.com> wrote:
>> 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...
>
> 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.

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

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

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

> On Wed, Jun 18, 2008 at 12:30 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Vegard Nossum <vegard.nossum@gmail.com> wrote:
> >> 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...
> >
> > 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.
> 
> 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")

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/thread_info_32.h
    	include/asm-x86/thread_info_64.h
    	include/asm-x86/topology.h
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

Re: [PATCH] x86: more header fixes

[Sam Ravnborg]

On Thu, Jun 26, 2008 at 02:02:02PM +0200, Ingo Molnar wrote:
> 
> * Vegard Nossum <vegard.nossum@gmail.com> wrote:
> 
> > Vegard (a.k.a. "The Churninator")

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

Re: [PATCH] x86: more header fixes

[Vegard Nossum]

On Thu, Jun 26, 2008 at 3:30 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> 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.

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

Re: [PATCH] x86: more header fixes

[Vegard Nossum]

Hi,

On Thu, Jun 26, 2008 at 2:02 PM, Ingo Molnar <mingo@elte.hu> wrote:
> 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?

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

Re: [PATCH] x86: more header fixes

[Sam Ravnborg]

On Thu, Jun 26, 2008 at 03:44:51PM +0200, Vegard Nossum wrote:
> On Thu, Jun 26, 2008 at 3:30 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> > 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.
> 
> 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.)

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
we decide to move the headers.


> 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>.
It is better to be explicit in the include than trying to do clever
tricks behind the bag og gcc.

	Sam

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

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

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

ok, lets do it that way.

> 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?

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

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Vegard Nossum <vegard.nossum@gmail.com> wrote:
> 
> > > 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?
> > 
> > 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.
> 
> ok, lets do it that way.

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

Re: [PATCH] x86: more header fixes

[Vegard Nossum]

On Wed, Jul 16, 2008 at 1:51 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>> * Vegard Nossum <vegard.nossum@gmail.com> wrote:
>>
>> > > 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?
>> >
>> > 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.
>>
>> ok, lets do it that way.
>
> ... 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?

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

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

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

> On Wed, Jul 16, 2008 at 1:51 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Ingo Molnar <mingo@elte.hu> wrote:
> >
> >> * Vegard Nossum <vegard.nossum@gmail.com> wrote:
> >>
> >> > > 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?
> >> >
> >> > 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.
> >>
> >> ok, lets do it that way.
> >
> > ... 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?
> 
> 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

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

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

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

	Ingo

Re: [PATCH] x86: more header fixes

[Vegard Nossum]

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.


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

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

* 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

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

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

> On Wed, Jul 16, 2008 at 4:22 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >> 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 ...
> 
> 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.

looks good - do you have a branch i could pull into 
tip/x86/header-guards?

	Ingo

Re: [PATCH] x86: more header fixes

[Vegard Nossum]

On Tue, Jul 22, 2008 at 12:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> 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.
>
> looks good - do you have a branch i could pull into
> tip/x86/header-guards?

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

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

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

> On Tue, Jul 22, 2008 at 12:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >> 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.
> >
> > looks good - do you have a branch i could pull into
> > tip/x86/header-guards?
> 
> 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.

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

Re: [PATCH] x86: more header fixes

[Vegard Nossum]

On Wed, Jul 16, 2008 at 4:22 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> 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 ...

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..3d1be4f 100644
--- a/arch/x86/kernel/syscall_64.c
+++ b/arch/x86/kernel/syscall_64.c
@@ -8,12 +8,12 @@
 #define __NO_STUBS
 
 #define __SYSCALL(nr, sym) extern asmlinkage void sym(void) ;
-#undef _ASM_X86_64_UNISTD_H_
+#undef ASM_X86__UNISTD_64_H
 #include <asm/unistd_64.h>
 
 #undef __SYSCALL
 #define __SYSCALL(nr, sym) [nr] = sym,
-#undef _ASM_X86_64_UNISTD_H_
+#undef ASM_X86__UNISTD_64_H
 
 typedef void (*sys_call_ptr_t)(void);
 
-- 
1.5.5.1


>From 8b7af7c2e502a0fdc1a0ce8f7b003249a226a107 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@gmail.com>
Date: Tue, 22 Jul 2008 13:56:36 +0200
Subject: [PATCH] x86: consolidate header guards

Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
---
 include/asm-x86/amd_iommu_types.h |    6 +++---
 include/asm-x86/dma-mapping.h     |    6 +++---
 include/asm-x86/ds.h              |    6 +++---
 include/asm-x86/pda.h             |    6 +++---
 include/asm-x86/vdso.h            |    6 +++---
 include/asm-x86/xen/interface.h   |    6 +++---
 6 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/include/asm-x86/amd_iommu_types.h b/include/asm-x86/amd_iommu_types.h
index 7bfcb47..20b5077 100644
--- a/include/asm-x86/amd_iommu_types.h
+++ b/include/asm-x86/amd_iommu_types.h
@@ -17,8 +17,8 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
  */
 
-#ifndef __AMD_IOMMU_TYPES_H__
-#define __AMD_IOMMU_TYPES_H__
+#ifndef ASM_X86__AMD_IOMMU_TYPES_H
+#define ASM_X86__AMD_IOMMU_TYPES_H
 
 #include <linux/types.h>
 #include <linux/list.h>
@@ -241,4 +241,4 @@ static inline void print_devid(u16 devid, int nl)
 		printk("\n");
 }
 
-#endif
+#endif /* ASM_X86__AMD_IOMMU_TYPES_H */
diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h
index a1a4dc7..0d817d0 100644
--- a/include/asm-x86/dma-mapping.h
+++ b/include/asm-x86/dma-mapping.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_DMA_MAPPING_H_
-#define _ASM_DMA_MAPPING_H_
+#ifndef ASM_X86__DMA_MAPPING_H
+#define ASM_X86__DMA_MAPPING_H
 
 /*
  * IOMMU interface. See Documentation/DMA-mapping.txt and DMA-API.txt for
@@ -234,4 +234,4 @@ extern void *
 dma_mark_declared_memory_occupied(struct device *dev,
 				  dma_addr_t device_addr, size_t size);
 #endif /* CONFIG_X86_32 */
-#endif
+#endif /* ASM_X86__DMA_MAPPING_H */
diff --git a/include/asm-x86/ds.h b/include/asm-x86/ds.h
index 7881368..6b27c68 100644
--- a/include/asm-x86/ds.h
+++ b/include/asm-x86/ds.h
@@ -17,8 +17,8 @@
  * Markus Metzger <markus.t.metzger@intel.com>, Dec 2007
  */
 
-#ifndef _ASM_X86_DS_H
-#define _ASM_X86_DS_H
+#ifndef ASM_X86__DS_H
+#define ASM_X86__DS_H
 
 #include <linux/types.h>
 #include <linux/init.h>
@@ -69,4 +69,4 @@ extern int ds_write_bts(void *, const struct bts_struct *);
 extern unsigned long ds_debugctl_mask(void);
 extern void __cpuinit ds_init_intel(struct cpuinfo_x86 *c);
 
-#endif /* _ASM_X86_DS_H */
+#endif /* ASM_X86__DS_H */
diff --git a/include/asm-x86/pda.h b/include/asm-x86/pda.h
index b34e9a7..80860af 100644
--- a/include/asm-x86/pda.h
+++ b/include/asm-x86/pda.h
@@ -1,5 +1,5 @@
-#ifndef X86_64_PDA_H
-#define X86_64_PDA_H
+#ifndef ASM_X86__PDA_H
+#define ASM_X86__PDA_H
 
 #ifndef __ASSEMBLY__
 #include <linux/stddef.h>
@@ -134,4 +134,4 @@ do {									\
 
 #define PDA_STACKOFFSET (5*8)
 
-#endif
+#endif /* ASM_X86__PDA_H */
diff --git a/include/asm-x86/vdso.h b/include/asm-x86/vdso.h
index 86e085e..4426394 100644
--- a/include/asm-x86/vdso.h
+++ b/include/asm-x86/vdso.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_X86_VDSO_H
-#define _ASM_X86_VDSO_H	1
+#ifndef ASM_X86__VDSO_H
+#define ASM_X86__VDSO_H
 
 #ifdef CONFIG_X86_64
 extern const char VDSO64_PRELINK[];
@@ -36,4 +36,4 @@ extern const char VDSO32_PRELINK[];
 extern void __user __kernel_sigreturn;
 extern void __user __kernel_rt_sigreturn;
 
-#endif	/* asm-x86/vdso.h */
+#endif /* ASM_X86__VDSO_H */
diff --git a/include/asm-x86/xen/interface.h b/include/asm-x86/xen/interface.h
index 6227000..1837d80 100644
--- a/include/asm-x86/xen/interface.h
+++ b/include/asm-x86/xen/interface.h
@@ -6,8 +6,8 @@
  * Copyright (c) 2004, K A Fraser
  */
 
-#ifndef __XEN_PUBLIC_ARCH_X86_32_H__
-#define __XEN_PUBLIC_ARCH_X86_32_H__
+#ifndef ASM_X86__XEN__INTERFACE_H
+#define ASM_X86__XEN__INTERFACE_H
 
 #ifdef __XEN__
 #define __DEFINE_GUEST_HANDLE(name, type) \
@@ -213,4 +213,4 @@ struct xen_callback {
 #define XEN_CPUID          XEN_EMULATE_PREFIX "cpuid"
 #endif
 
-#endif
+#endif /* ASM_X86__XEN__INTERFACE_H */
-- 
1.5.5.1

Re: [PATCH] x86: more header fixes

[Vegard Nossum]

On Tue, Jul 22, 2008 at 1:38 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> Though I still believe it should be squashed for bisectability.
>
> hm, i pulled it but 1ab9e368 cannot be squashed into aa27f9586 cleanly.

Yes, you are right. I forgot to check.

> 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?

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

Re: [PATCH] x86: more header fixes

[Ingo Molnar]

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

> On Tue, Jul 22, 2008 at 1:38 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >> Though I still believe it should be squashed for bisectability.
> >
> > hm, i pulled it but 1ab9e368 cannot be squashed into aa27f9586 cleanly.
> 
> Yes, you are right. I forgot to check.
> 
> > 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?
> 
> 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.

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