2.5.3-pre1 compile error

2.5.3-pre1 compile error

[John Weber]

gcc -D__KERNEL__ -I/usr/src/linux-2.5.2/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 
-march=i686    -c -o read_write.o read_write.c
In file included from read_write.c:10:
/usr/src/linux-2.5.2/include/linux/file.h:25: parse error before `atomic_t'
/usr/src/linux-2.5.2/include/linux/file.h:25: warning: no semicolon at 
end of struct or union
/usr/src/linux-2.5.2/include/linux/file.h:36: parse error before `}'
/usr/src/linux-2.5.2/include/linux/file.h: In function `fcheck_files':
/usr/src/linux-2.5.2/include/linux/file.h:50: dereferencing pointer to 
incomplete type
/usr/src/linux-2.5.2/include/linux/file.h:51: dereferencing pointer to 
incomplete type
In file included from read_write.c:13:
/usr/src/linux-2.5.2/include/linux/dnotify.h: At top level:
/usr/src/linux-2.5.2/include/linux/dnotify.h:18: warning: `struct inode' 
declared inside parameter list
/usr/src/linux-2.5.2/include/linux/dnotify.h:18: warning: its scope is 
only this definition or declaration, which is probably not what you want.
/usr/src/linux-2.5.2/include/linux/dnotify.h:21: warning: `struct inode' 
declared inside parameter list
/usr/src/linux-2.5.2/include/linux/dnotify.h: In function 
`inode_dir_notify':
/usr/src/linux-2.5.2/include/linux/dnotify.h:23: dereferencing pointer 
to incomplete type
/usr/src/linux-2.5.2/include/linux/dnotify.h:24: warning: passing arg 1 
of `__inode_dir_notify' from incompatible pointer type
read_write.c: In function `sys_read':
read_write.c:167: warning: passing arg 1 of `inode_dir_notify' from 
incompatible pointer type
read_write.c: In function `sys_write':
read_write.c:194: warning: passing arg 1 of `inode_dir_notify' from 
incompatible pointer type
read_write.c: In function `do_readv_writev':
read_write.c:299: warning: passing arg 1 of `inode_dir_notify' from 
incompatible pointer type
read_write.c: In function `sys_pread':
read_write.c:371: warning: passing arg 1 of `inode_dir_notify' from 
incompatible pointer type
read_write.c: In function `sys_pwrite':
read_write.c:403: warning: passing arg 1 of `inode_dir_notify' from 
incompatible pointer type
make[2]: *** [read_write.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.5.2/fs'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.5.2/fs'
make: *** [_dir_fs] Error 2

[PATCH] Re: 2.5.3-pre1 compile error

[Benjamin LaHaise]

On Tue, Jan 15, 2002 at 07:05:10PM -0500, John Weber wrote:
> incompatible pointer type
> read_write.c: In function `sys_pwrite':
> read_write.c:403: warning: passing arg 1 of `inode_dir_notify' from 
> incompatible pointer type

Hmm, this should fix that.

		-ben

:r ~/patches/v2.5.3-pre1-file_fix.diff
diff -urN v2.5.3-pre1/include/linux/file.h v2.5.3-pre1-fix/include/linux/file.h
--- v2.5.3-pre1/include/linux/file.h	Tue Jan 15 19:11:11 2002
+++ v2.5.3-pre1-fix/include/linux/file.h	Tue Jan 15 19:20:06 2002
@@ -5,6 +5,9 @@
 #ifndef __LINUX_FILE_H
 #define __LINUX_FILE_H
 
+#ifndef __ASM__ATOMIC_H
+#include <asm/atomic.h>
+#endif
 #ifndef _LINUX_POSIX_TYPES_H	/* __FD_CLR */
 #include <linux/posix_types.h>
 #endif

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Linus Torvalds]

On Tue, 15 Jan 2002, Benjamin LaHaise wrote:
>
> Hmm, this should fix that.

probably will, BUT..

> +#ifndef __ASM__ATOMIC_H
> +#include <asm/atomic.h>
> +#endif

Please do not assume knowdledge of what the different header files use to
define their re-entrancy.

Just do

	#include <asm/atomic.h>

and be done with it.

		Linus

Re: [PATCH] Re: 2.5.3-pre1 compile error

[David Weinehall]

On Tue, Jan 15, 2002 at 04:29:38PM -0800, Linus Torvalds wrote:
> 
> On Tue, 15 Jan 2002, Benjamin LaHaise wrote:
> >
> > Hmm, this should fix that.
> 
> probably will, BUT..
> 
> > +#ifndef __ASM__ATOMIC_H
> > +#include <asm/atomic.h>
> > +#endif
> 
> Please do not assume knowdledge of what the different header files use to
> define their re-entrancy.
> 
> Just do
> 
> 	#include <asm/atomic.h>
> 
> and be done with it.

The lines below say:

#ifndef _LINUX_POSIX_TYPES_H   /* __FD_CLR */
#include <linux/posix_types.h>
#endif


Maybe fix this while at it?!


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Linus Torvalds]

On Wed, 16 Jan 2002, David Weinehall wrote:
> >
> > Just do
> >
> > 	#include <asm/atomic.h>
> >
> > and be done with it.
>
> The lines below say:
>
> #ifndef _LINUX_POSIX_TYPES_H   /* __FD_CLR */
> #include <linux/posix_types.h>
> #endif

At least that doesn't depend on all architectures having the same
exclusion-defines, but yeah, it's ugly too.

If this actally makes any noticeable difference to compilation speed I
could live with it. Does it?

		Linus

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Dave Jones]

On Tue, Jan 15, 2002 at 04:41:08PM -0800, Linus Torvalds wrote:
 > > #ifndef _LINUX_POSIX_TYPES_H   /* __FD_CLR */
 > > #include <linux/posix_types.h>
 > > #endif
 > If this actally makes any noticeable difference to compilation speed I
 > could live with it. Does it?

 I'm sure I read somewhere that gcc is clever enough to know
 when it hits a #include, it checks for a symbol equal to a
 mangled version of the filename before including it.
 (Ie, doing this transparently).

 Then again, I may have imagined it all.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] Re: 2.5.3-pre1 compile error

[dmeyer]

In article <20020116015513.L32088@suse.de> you write:
> On Tue, Jan 15, 2002 at 04:41:08PM -0800, Linus Torvalds wrote:
>  > > #ifndef _LINUX_POSIX_TYPES_H   /* __FD_CLR */
>  > > #include <linux/posix_types.h>
>  > > #endif
>  > If this actally makes any noticeable difference to compilation speed I
>  > could live with it. Does it?
> 
>  I'm sure I read somewhere that gcc is clever enough to know
>  when it hits a #include, it checks for a symbol equal to a
>  mangled version of the filename before including it.
>  (Ie, doing this transparently).
> 
>  Then again, I may have imagined it all.

I'm pretty sure you did, since it's perfectly legal (and occasionally
useful, if gruesome) to do

#define THE_STRUCT struct1
#include "struct_def.h"
#undef THE_STRUCT
#define THE_STRUCT struct2
#include "struct_def.h"

and have both #includes work.  You may be thinking of #import, which
is deprecated except for objective-c, IIRC.

In answer to Linus' question...yes, in a large system redundent
include guards can make a real difference, particularly for headers
which get included by other headers regularly.  OTOH, my last
experience using them was on an underpowered Solaris box, which (a)
didn't have enough memory for all the developers compiling on it and
(b) was running an old Solaris, so its read caching was pretty lame
anyway.  It makes rather a lot of difference if the preprocessor has
to read <linux/posix_types.h> from the disk 20 times or if it can get
it from the file cache 20 times.

-- 
Dave Meyer
dmeyer@dmeyer.net

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Peter Osterlund]

Dave Jones <davej@suse.de> writes:

> On Tue, Jan 15, 2002 at 04:41:08PM -0800, Linus Torvalds wrote:
>  > > #ifndef _LINUX_POSIX_TYPES_H   /* __FD_CLR */
>  > > #include <linux/posix_types.h>
>  > > #endif
>  > If this actally makes any noticeable difference to compilation speed I
>  > could live with it. Does it?
> 
>  I'm sure I read somewhere that gcc is clever enough to know
>  when it hits a #include, it checks for a symbol equal to a
>  mangled version of the filename before including it.
>  (Ie, doing this transparently).
> 
>  Then again, I may have imagined it all.

Not exactly, but there is an optimization in cpp that makes it
possible to do the cleanup Linus wants without sacrificing
performance. From the cpp info pages:

        The GNU C preprocessor is programmed to notice when a header
        file uses this particular construct and handle it efficiently.
        If a header file is contained entirely in a `#ifndef'
        conditional, modulo whitespace and comments, then it remembers
        that fact.  If a subsequent `#include' specifies the same
        file, and the macro in the `#ifndef' is already defined, then
        the directive is skipped without processing the specified file
        at all.

I did an strace on cpp to verify that this optimization actually
works.

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Benjamin LaHaise]

On Tue, Jan 15, 2002 at 04:29:38PM -0800, Linus Torvalds wrote:
> > +#ifndef __ASM__ATOMIC_H
> > +#include <asm/atomic.h>
> > +#endif
> 
> Please do not assume knowdledge of what the different header files use to
> define their re-entrancy.

Well, I actually disagree on this.  For large include files (fs.h is the 
worst), and complicated arrangement, this technique eliminates spurious 
includes and saves a lot on compile time (really!).  If your concern is 
that the convention is not consistent, I'll gladly patch all of them to 
use the same format (ie use an __ prefix and escape / to __ and . to _).

		-ben

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Linus Torvalds]

On Tue, 15 Jan 2002, Benjamin LaHaise wrote:
>
> Well, I actually disagree on this.  For large include files (fs.h is the
> worst), and complicated arrangement, this technique eliminates spurious
> includes and saves a lot on compile time (really!).

Numbers please.

I'd MUCH rather just clean up the include file hierarchy than have these
kinds of non-local knowledge issues.

		Linus

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Benjamin LaHaise]

On Tue, Jan 15, 2002 at 04:44:54PM -0800, Linus Torvalds wrote:
> Numbers please.
> 
> I'd MUCH rather just clean up the include file hierarchy than have these
> kinds of non-local knowledge issues.

The last time I did it for fs.h et al (this meant pulling the fs.h and 
sched.h codependancy apart), it got 2.4 compiles back down to 2.2 compile 
times (3m -> 2m45s maybe 2m30s iirc) -- about a 10% drop in compile time.  
It's even more noticeable when you're doing a fully blown modular kernel 
build as distributions do.

		-ben
-- 
Fish.

Re: [PATCH] Re: 2.5.3-pre1 compile error

[David Weinehall]

On Tue, Jan 15, 2002 at 07:52:04PM -0500, Benjamin LaHaise wrote:
> On Tue, Jan 15, 2002 at 04:44:54PM -0800, Linus Torvalds wrote:
> > Numbers please.
> > 
> > I'd MUCH rather just clean up the include file hierarchy than have these
> > kinds of non-local knowledge issues.
> 
> The last time I did it for fs.h et al (this meant pulling the fs.h and 
> sched.h codependancy apart), it got 2.4 compiles back down to 2.2 compile 
> times (3m -> 2m45s maybe 2m30s iirc) -- about a 10% drop in compile time.  
> It's even more noticeable when you're doing a fully blown modular kernel 
> build as distributions do.

The difference between 3 minutes and 2.45 isn't really a lot imho. What
is interesting if difference scales; that is, if you compile on a 486
or so, does the 10% drop still hold, or are we still talking about a
difference of 15 seconds. If the latter, I'd go for the cleanup,
but if the former is true, maybe, just maybe, the ugly version might
be the solution.

I'd prefer all includes that can be to be non-conditional, though.


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Christopher Turcksin]

Linus Torvalds wrote:

> > Well, I actually disagree on this.  For large include files (fs.h is the
> > worst), and complicated arrangement, this technique eliminates spurious
> > includes and saves a lot on compile time (really!).
> 
> Numbers please.

The GNU C preprocessor remembers if an include file was completely
inside an #ifndef/#endif conditional (modulo whitespace and comments)
and will skip the #include for the same file if the macro in #ifndef is
already defined. I suspect putting guards around the include will not
save any more time.

bfn,
Christopher Turcksin <turcksin@uk.ibm.com>

IBM Global Services

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Robert Love]

On Tue, 2002-01-15 at 19:43, Benjamin LaHaise wrote:
> +#ifndef __ASM__ATOMIC_H
> +#include <asm/atomic.h>
> +#endif

gcc -D__KERNEL__ -I/home/rml/src/linux/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon     -c -o brlock.o brlock.c
brlock.c:21: initializer element is not constant
brlock.c:21: (near initialization for `__brlock_array[0][0]')
... for all the [x][y] elements ...
brlock.c:21: initializer element is not constant
brlock.c:21: (near initialization for `__brlock_array[31]')

I get this compile error under 2.5.3-pre1, too.  System is SMP.  2.5.2
worked fine.  I don't see a thing in the patch that would cause this ...

	Robert Love

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Benjamin LaHaise]

On Tue, Jan 15, 2002 at 08:24:22PM -0500, Robert Love wrote:
> I get this compile error under 2.5.3-pre1, too.  System is SMP.  2.5.2
> worked fine.  I don't see a thing in the patch that would cause this ...

Uh, brlock.c probably should be including threads.h...

-- 
Fish.

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Robert Love]

On Tue, 2002-01-15 at 20:25, Benjamin LaHaise wrote:

> Uh, brlock.c probably should be including threads.h...

lib/brlock.c includes include/linux/sched.h which includes
include/linux/threads.h ...

	Robert Love

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Davide Libenzi]

On Tue, 15 Jan 2002, Linus Torvalds wrote:

>
> On Tue, 15 Jan 2002, Benjamin LaHaise wrote:
> >
> > Hmm, this should fix that.
>
> probably will, BUT..
>
> > +#ifndef __ASM__ATOMIC_H
> > +#include <asm/atomic.h>
> > +#endif
>
> Please do not assume knowdledge of what the different header files use to
> define their re-entrancy.
>
> Just do
>
> 	#include <asm/atomic.h>
>
> and be done with it.

I needed two fixes :

#include <asm/atomic.h> in include/linux/file.h

#include <linux/fs.h> in include/linux/dnotify.h

after that it builds for me ... but it crashes at boot time




- Davide

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Linus Torvalds]

On Tue, 15 Jan 2002, Davide Libenzi wrote:
>
> after that it builds for me ... but it crashes at boot time

Where?

The main big thing in 2.5.3-pre1 is the IDE driver update, the rest looks
fairly simple. I've tested the new IDE driver on my system (the famous
"Works For Me" test), and it's been tested quite a lot in earlier
incarnations on other platforms, but there might easily be some BIO or
low-level IDE chipset interactions.

If it's not in the IDE driver, I'm at a loss.

		Linus

Re: [PATCH] Re: 2.5.3-pre1 compile error

[David S. Miller]

   From: Linus Torvalds <torvalds@transmeta.com>
   Date: Tue, 15 Jan 2002 16:43:58 -0800 (PST)
   
   If it's not in the IDE driver, I'm at a loss.

That "#if 1" buisness in the new ide-dma.c code looks
really suspicious...

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Andre Hedrick]

Well if you look at it closely, that function.

"ide_raw_build_sglist()"

 is not called except from the user-space diagnostics ioctl

You that is getting called with from a BIO request, there will be major
request completion problems.

That is there to allow a future "Alex Viro" suggestion be considered.


On Tue, 15 Jan 2002, David S. Miller wrote:

>    From: Linus Torvalds <torvalds@transmeta.com>
>    Date: Tue, 15 Jan 2002 16:43:58 -0800 (PST)
>    
>    If it's not in the IDE driver, I'm at a loss.
> 
> That "#if 1" buisness in the new ide-dma.c code looks
> really suspicious...

Andre Hedrick
Linux Disk Certification Project                Linux ATA Development

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Davide Libenzi]

On Tue, 15 Jan 2002, Linus Torvalds wrote:

>
> On Tue, 15 Jan 2002, Davide Libenzi wrote:
> >
> > after that it builds for me ... but it crashes at boot time
>
> Where?
>
> The main big thing in 2.5.3-pre1 is the IDE driver update, the rest looks
> fairly simple. I've tested the new IDE driver on my system (the famous
> "Works For Me" test), and it's been tested quite a lot in earlier
> incarnations on other platforms, but there might easily be some BIO or
> low-level IDE chipset interactions.
>
> If it's not in the IDE driver, I'm at a loss.

Doh !

Trace; c0113988 <schedule+118/2b0>
Trace; c01075cd <sys_clone+1d/30>
Trace; c0105020 <init+0/140>
Trace; c0105000 <_stext+0/0>
Trace; c010720d <kernel_thread+1d/30>
Trace; c0105011 <rest_init+11/20>

Let me try something ...




- Davide

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Davide Libenzi]

On Tue, 15 Jan 2002, Davide Libenzi wrote:

> Doh !
>
> Trace; c0113988 <schedule+118/2b0>
> Trace; c01075cd <sys_clone+1d/30>
> Trace; c0105020 <init+0/140>
> Trace; c0105000 <_stext+0/0>
> Trace; c010720d <kernel_thread+1d/30>
> Trace; c0105011 <rest_init+11/20>
>
> Let me try something ...

Ehmmm, let's do like if nothing happened :-)




- Davide

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Davide Libenzi]

On Tue, 15 Jan 2002, Benjamin LaHaise wrote:

> On Tue, Jan 15, 2002 at 04:46:36PM -0800, Davide Libenzi wrote:
> > after that it builds for me ... but it crashes at boot time
>
> Config?  Arch?  Compiler?

Let me reboot with the crashing kernel for tracing ...

x86 UP Athlon gcc-3.0.3




- Davide

Re: [PATCH] Re: 2.5.3-pre1 compile error

[David Weinehall]

On Tue, Jan 15, 2002 at 04:52:23PM -0800, Davide Libenzi wrote:
> On Tue, 15 Jan 2002, Benjamin LaHaise wrote:
> 
> > On Tue, Jan 15, 2002 at 04:46:36PM -0800, Davide Libenzi wrote:
> > > after that it builds for me ... but it crashes at boot time
> >
> > Config?  Arch?  Compiler?
> 
> Let me reboot with the crashing kernel for tracing ...
> 
> x86 UP Athlon gcc-3.0.3

Let me suggest gcc-2.95.3 or gcc-2.96-whatever


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Davide Libenzi]

On Wed, 16 Jan 2002, David Weinehall wrote:

> On Tue, Jan 15, 2002 at 04:52:23PM -0800, Davide Libenzi wrote:
> > On Tue, 15 Jan 2002, Benjamin LaHaise wrote:
> >
> > > On Tue, Jan 15, 2002 at 04:46:36PM -0800, Davide Libenzi wrote:
> > > > after that it builds for me ... but it crashes at boot time
> > >
> > > Config?  Arch?  Compiler?
> >
> > Let me reboot with the crashing kernel for tracing ...
> >
> > x86 UP Athlon gcc-3.0.3
>
> Let me suggest gcc-2.95.3 or gcc-2.96-whatever

No you should suggest me to check my code :-)




- Davide

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Russ Allbery]

dmeyer <dmeyer@dmeyer.net> writes:
> In article <20020116015513.L32088@suse.de> you write:

>>  I'm sure I read somewhere that gcc is clever enough to know when it
>>  hits a #include, it checks for a symbol equal to a mangled version of
>>  the filename before including it.  (Ie, doing this transparently).

>>  Then again, I may have imagined it all.

No, you read that gcc notices when the entirety of a source file is
wrapped in an #ifdef guard and won't re-read that file when it's included
again if the symbol is defined.

> In answer to Linus' question...yes, in a large system redundent include
> guards can make a real difference, particularly for headers which get
> included by other headers regularly.

Yes, but you don't need to put them around the #include.  Just make sure
there is nothing but comments outside the multiple inclusion guards in the
header files and any competent compiler will do the right thing.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Andi Kleen]

Linus Torvalds <torvalds@transmeta.com> writes:
> 
> > +#ifndef __ASM__ATOMIC_H
> > +#include <asm/atomic.h>
> > +#endif
> 
> Please do not assume knowdledge of what the different header files use to
> define their re-entrancy.
> 
> Just do
> 
> 	#include <asm/atomic.h>
> 
> and be done with it.

The first check is done automatically by the gcc preprocessor 
anyways (it has a special check for the #ifndef BLA_H #define BLA_H #endif
construct for whole files and doesn't even bother to open them again on a 
second include). So it's completely unnecessary. 

Someone added some of these useless checks to 2.5.3pre1. Here is a patch
to remove them. Please consider applying.

--- linux-2.5.3pre1/include/linux/file.h-o	Wed Jan 16 12:24:09 2002
+++ linux-2.5.3pre1/include/linux/file.h	Wed Jan 16 12:25:10 2002
@@ -5,12 +5,8 @@
 #ifndef __LINUX_FILE_H
 #define __LINUX_FILE_H
 
-#ifndef _LINUX_POSIX_TYPES_H	/* __FD_CLR */
 #include <linux/posix_types.h>
-#endif
-#ifndef __LINUX_COMPILER_H	/* unlikely */
 #include <linux/compiler.h>
-#endif
 
 /*
  * The default fd array needs to be at least BITS_PER_LONG,
--- linux-2.5.3pre1/include/linux/init_task.h-o	Wed Jan 16 12:24:09 2002
+++ linux-2.5.3pre1/include/linux/init_task.h	Wed Jan 16 12:25:27 2002
@@ -1,9 +1,7 @@
 #ifndef _LINUX__INIT_TASK_H
 #define _LINUX__INIT_TASK_H
 
-#ifndef __LINUX_FILE_H
 #include <linux/file.h>
-#endif
 
 #define INIT_FILES \
 { 							\


-Andi

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Dave Jones]

On 16 Jan 2002, Andi Kleen wrote:

> The first check is done automatically by the gcc preprocessor
> anyways (it has a special check for the #ifndef BLA_H #define BLA_H #endif
> construct for whole files and doesn't even bother to open them again on a
> second include). So it's completely unnecessary.

Ahah! I knew I didn't imagine it. Either that or we've both had the same
hallucination. 8-)

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] Re: 2.5.3-pre1 compile error

[Neil Booth]

Dave Jones wrote:-

> On 16 Jan 2002, Andi Kleen wrote:
> 
> > The first check is done automatically by the gcc preprocessor
> > anyways (it has a special check for the #ifndef BLA_H #define BLA_H #endif
> > construct for whole files and doesn't even bother to open them again on a
> > second include). So it's completely unnecessary.
> 
> Ahah! I knew I didn't imagine it. Either that or we've both had the same
> hallucination. 8-)

I told you over a beer, so maybe you were hallucinating 8^)

Neil.