All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
@ 2006-01-09 17:15 ` Jeff Mahoney
  0 siblings, 0 replies; 10+ 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] 10+ messages in thread

* [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
@ 2006-01-09 17:15 ` Jeff Mahoney
  0 siblings, 0 replies; 10+ 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] 10+ messages in thread

* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
  2006-01-09 17:15 ` Jeff Mahoney
@ 2006-01-09 17:21   ` Matthew Wilcox
  -1 siblings, 0 replies; 10+ 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] 10+ messages in thread

* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
@ 2006-01-09 17:21   ` Matthew Wilcox
  0 siblings, 0 replies; 10+ 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] 10+ messages in thread

* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
  2006-01-09 17:15 ` Jeff Mahoney
@ 2006-01-09 17:25   ` Christoph Hellwig
  -1 siblings, 0 replies; 10+ 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] 10+ messages in thread

* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
@ 2006-01-09 17:25   ` Christoph Hellwig
  0 siblings, 0 replies; 10+ 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] 10+ messages in thread

* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation
  2006-01-09 17:25   ` Christoph Hellwig
@ 2006-01-09 17:32     ` Jeff Mahoney
  -1 siblings, 0 replies; 10+ 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] 10+ messages in thread

* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
@ 2006-01-09 17:32     ` Jeff Mahoney
  0 siblings, 0 replies; 10+ 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] 10+ messages in thread

* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation
  2006-01-09 17:21   ` Matthew Wilcox
@ 2006-01-09 17:42     ` Jeff Mahoney
  -1 siblings, 0 replies; 10+ 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] 10+ messages in thread

* Re: [PATCH] ia64: including <asm/signal.h> alone causes compilation errors
@ 2006-01-09 17:42     ` Jeff Mahoney
  0 siblings, 0 replies; 10+ 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] 10+ messages in thread

end of thread, other threads:[~2006-01-09 17:42 UTC | newest]

Thread overview: 10+ 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:15 ` Jeff Mahoney
2006-01-09 17:21 ` Matthew Wilcox
2006-01-09 17:21   ` Matthew Wilcox
2006-01-09 17:42   ` [PATCH] ia64: including <asm/signal.h> alone causes compilation Jeff Mahoney
2006-01-09 17:42     ` [PATCH] ia64: including <asm/signal.h> alone causes compilation errors Jeff Mahoney
2006-01-09 17:25 ` Christoph Hellwig
2006-01-09 17:25   ` Christoph Hellwig
2006-01-09 17:32   ` [PATCH] ia64: including <asm/signal.h> alone causes compilation Jeff Mahoney
2006-01-09 17:32     ` [PATCH] ia64: including <asm/signal.h> alone causes compilation errors Jeff Mahoney

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.