* [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
@ 2006-01-09 17:15 Jeff Mahoney
2006-01-09 17:21 ` Matthew Wilcox
2006-01-09 17:25 ` Christoph Hellwig
0 siblings, 2 replies; 5+ messages in thread
From: Jeff Mahoney @ 2006-01-09 17:15 UTC (permalink / raw)
To: linux-ia64; +Cc: Linux Kernel Mailing List
Including *just* <asm/signal.h> on ia64 will result in a compilation failure,
where it will succeed on every other architecture.
Every other arch includes <linux/compiler.h> either directly or via
<linux/types.h> at the top of <asm-*/signal.h>. ia64 includes
<linux/types.h> after including <asm-generic/signal.h>, which causes
the __user in <asm-generic/signal.h> to get passed through untouched, causing
compilation errors.
This patch moves the #include <linux/types.h> up to the beginning of signal.h,
as found on every other arch.
A specific example of where this behavior is observed is the recent addition
of OCFS2. fs/ocfs2/cluster/userdlm.c seems alone in only including
<asm/signal.h>, which seems to be perfectly valid.
While I could have just fixed this in the OCFS2 code, I thought that making
ia64 more consistent with the rest of the kernel would be the better fix.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
diff -ruNpX dontdiff linux-2.6.15/include/asm-ia64/signal.h linux-2.6.15-ocfs2/include/asm-ia64/signal.h
--- linux-2.6.15/include/asm-ia64/signal.h 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.15-ocfs2/include/asm-ia64/signal.h 2006-01-09 11:08:16.404700640 -0500
@@ -1,6 +1,8 @@
#ifndef _ASM_IA64_SIGNAL_H
#define _ASM_IA64_SIGNAL_H
+#include <linux/types.h>
+
/*
* Modified 1998-2001, 2003
* David Mosberger-Tang <davidm@hpl.hp.com>, Hewlett-Packard Co
@@ -122,8 +124,6 @@
# ifndef __ASSEMBLY__
-# include <linux/types.h>
-
/* Avoid too many header ordering problems. */
struct siginfo;
--
Jeff Mahoney
SuSE Labs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
2006-01-09 17:15 [PATCH] ia64: including <asm/signal.h> alone causes compilation errors Jeff Mahoney
@ 2006-01-09 17:21 ` Matthew Wilcox
2006-01-09 17:42 ` Jeff Mahoney
2006-01-09 17:25 ` Christoph Hellwig
1 sibling, 1 reply; 5+ messages in thread
From: Matthew Wilcox @ 2006-01-09 17:21 UTC (permalink / raw)
To: Jeff Mahoney; +Cc: linux-ia64, Linux Kernel Mailing List
On Mon, Jan 09, 2006 at 12:15:14PM -0500, Jeff Mahoney wrote:
> +++ linux-2.6.15-ocfs2/include/asm-ia64/signal.h 2006-01-09 11:08:16.404700640 -0500
> @@ -1,6 +1,8 @@
> #ifndef _ASM_IA64_SIGNAL_H
> #define _ASM_IA64_SIGNAL_H
>
> +#include <linux/types.h>
> +
> /*
> * Modified 1998-2001, 2003
> * David Mosberger-Tang <davidm@hpl.hp.com>, Hewlett-Packard Co
> @@ -122,8 +124,6 @@
>
> # ifndef __ASSEMBLY__
>
> -# include <linux/types.h>
> -
> /* Avoid too many header ordering problems. */
> struct siginfo;
Is it still possible to include this file from assembly? Do we still
need to do that?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
2006-01-09 17:15 [PATCH] ia64: including <asm/signal.h> alone causes compilation errors Jeff Mahoney
2006-01-09 17:21 ` Matthew Wilcox
@ 2006-01-09 17:25 ` Christoph Hellwig
2006-01-09 17:32 ` Jeff Mahoney
1 sibling, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2006-01-09 17:25 UTC (permalink / raw)
To: Jeff Mahoney; +Cc: linux-ia64, Linux Kernel Mailing List
On Mon, Jan 09, 2006 at 12:15:14PM -0500, Jeff Mahoney wrote:
>
> Including *just* <asm/signal.h> on ia64 will result in a compilation failure,
> where it will succeed on every other architecture.
>
> Every other arch includes <linux/compiler.h> either directly or via
> <linux/types.h> at the top of <asm-*/signal.h>. ia64 includes
> <linux/types.h> after including <asm-generic/signal.h>, which causes
> the __user in <asm-generic/signal.h> to get passed through untouched, causing
> compilation errors.
>
> This patch moves the #include <linux/types.h> up to the beginning of signal.h,
> as found on every other arch.
>
> A specific example of where this behavior is observed is the recent addition
> of OCFS2. fs/ocfs2/cluster/userdlm.c seems alone in only including
> <asm/signal.h>, which seems to be perfectly valid.
Generally you should only include <asm/signal.h> via <linux/signal.h>, which gets
<linux/compiler.h> via <linux/spinlock.h>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
2006-01-09 17:25 ` Christoph Hellwig
@ 2006-01-09 17:32 ` Jeff Mahoney
0 siblings, 0 replies; 5+ messages in thread
From: Jeff Mahoney @ 2006-01-09 17:32 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ia64, Linux Kernel Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christoph Hellwig wrote:
> On Mon, Jan 09, 2006 at 12:15:14PM -0500, Jeff Mahoney wrote:
>> Including *just* <asm/signal.h> on ia64 will result in a compilation failure,
>> where it will succeed on every other architecture.
>>
>> Every other arch includes <linux/compiler.h> either directly or via
>> <linux/types.h> at the top of <asm-*/signal.h>. ia64 includes
>> <linux/types.h> after including <asm-generic/signal.h>, which causes
>> the __user in <asm-generic/signal.h> to get passed through untouched, causing
>> compilation errors.
>>
>> This patch moves the #include <linux/types.h> up to the beginning of signal.h,
>> as found on every other arch.
>>
>> A specific example of where this behavior is observed is the recent addition
>> of OCFS2. fs/ocfs2/cluster/userdlm.c seems alone in only including
>> <asm/signal.h>, which seems to be perfectly valid.
>
> Generally you should only include <asm/signal.h> via <linux/signal.h>, which gets
> <linux/compiler.h> via <linux/spinlock.h>
Ok. I just did a quick grep and saw a number of places where
<asm/signal.h> was included. A closer look reveals most of those are in
arch/.
Ignore the noise.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDwp5DLPWxlyuTD7IRAoZBAKCf4MMQNC/rfcdXOH0Dto3RTa32qgCfSeFf
pX68kyrbj2ZdH23Mo+EmUZ4=
=y7xp
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
2006-01-09 17:21 ` Matthew Wilcox
@ 2006-01-09 17:42 ` Jeff Mahoney
0 siblings, 0 replies; 5+ messages in thread
From: Jeff Mahoney @ 2006-01-09 17:42 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-ia64, Linux Kernel Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthew Wilcox wrote:
> On Mon, Jan 09, 2006 at 12:15:14PM -0500, Jeff Mahoney wrote:
>> +++ linux-2.6.15-ocfs2/include/asm-ia64/signal.h 2006-01-09 11:08:16.404700640 -0500
>> @@ -1,6 +1,8 @@
>> #ifndef _ASM_IA64_SIGNAL_H
>> #define _ASM_IA64_SIGNAL_H
>>
>> +#include <linux/types.h>
>> +
>> /*
>> * Modified 1998-2001, 2003
>> * David Mosberger-Tang <davidm@hpl.hp.com>, Hewlett-Packard Co
>> @@ -122,8 +124,6 @@
>>
>> # ifndef __ASSEMBLY__
>>
>> -# include <linux/types.h>
>> -
>> /* Avoid too many header ordering problems. */
>> struct siginfo;
>
> Is it still possible to include this file from assembly? Do we still
> need to do that?
>
>
Yes, actually, it is. :(
Christoph also pointed out that including <linux/signal.h> is the better
solution, so I'm submitting that patch to the OCFS2 folks instead.
Sorry for the noise.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDwqCjLPWxlyuTD7IRAj8PAJwLv2EghfMR9yPuaVhpTLQMGysKpwCfcVBq
7ZT0LwuYEjKYVnJT/QeXmCw=
=Yt8o
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-01-09 17:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-09 17:15 [PATCH] ia64: including <asm/signal.h> alone causes compilation errors Jeff Mahoney
2006-01-09 17:21 ` Matthew Wilcox
2006-01-09 17:42 ` Jeff Mahoney
2006-01-09 17:25 ` Christoph Hellwig
2006-01-09 17:32 ` Jeff Mahoney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).