[Linux-ia64] C++ doesn't like asm/atomic.h

[Linux-ia64] C++ doesn't like asm/atomic.h

[Gary Hade]

asm/atomic.h is not palatable to C++ due to it's use 
of the C++ keyword "new".

Script started on Fri Apr  5 12:03:38 2002
elm3a87.eng:/home/garyh cat x.C
#include <asm/atomic.h>
elm3a87.eng:/home/garyh c++ -c x.C
In file included from x.C:1:
/usr/include/asm/atomic.h: In function `int ia64_atomic_add (int,
atomic_t *)':
/usr/include/asm/atomic.h:33: parse error before `new'
/usr/include/asm/atomic.h:39: parse error before `='
/usr/include/asm/atomic.h:41: parse error before `;'
/usr/include/asm/atomic.h: In function `int ia64_atomic_sub (int,
atomic_t *)':
/usr/include/asm/atomic.h:47: parse error before `new'
/usr/include/asm/atomic.h:53: parse error before `='
/usr/include/asm/atomic.h:54: parse error before `)'
/usr/include/asm/atomic.h:54: `_n_' undeclared (first use this
function)
/usr/include/asm/atomic.h:54: (Each undeclared identifier is reported
only once for each function it appears in.)
/usr/include/asm/atomic.h:55: parse error before `;'
elm3a87.eng:/home/garyh exit
exit

Script done on Fri Apr	5 12:03:55 2002

Patch for 2.4.18 included below.

Gary

-- 
Gary Hade
IBM Linux Technology Center
503-578-4503  IBM T/L: 775-4503
garyhade@us.ibm.com
http://www.ibm.com/linux/ltc


--- linux/include/asm-ia64/atomic.h.orig	Fri Apr  5 11:56:12 2002
+++ linux/include/asm-ia64/atomic.h	Fri Apr  5 11:55:21 2002
@@ -30,29 +30,29 @@
 static __inline__ int
 ia64_atomic_add (int i, atomic_t *v)
 {
-	__s32 old, new;
+	__s32 old_val, new_val;
 	CMPXCHG_BUGCHECK_DECL
 
 	do {
 		CMPXCHG_BUGCHECK(v);
-		old = atomic_read(v);
-		new = old + i;
-	} while (ia64_cmpxchg("acq", v, old, old + i, sizeof(atomic_t)) != old);
-	return new;
+		old_val = atomic_read(v);
+		new_val = old_val + i;
+	} while (ia64_cmpxchg("acq", v, old_val, old_val + i, sizeof(atomic_t)) != old_val);
+	return new_val;
 }
 
 static __inline__ int
 ia64_atomic_sub (int i, atomic_t *v)
 {
-	__s32 old, new;
+	__s32 old_val, new_val;
 	CMPXCHG_BUGCHECK_DECL
 
 	do {
 		CMPXCHG_BUGCHECK(v);
-		old = atomic_read(v);
-		new = old - i;
-	} while (ia64_cmpxchg("acq", v, old, new, sizeof(atomic_t)) != old);
-	return new;
+		old_val = atomic_read(v);
+		new_val = old_val - i;
+	} while (ia64_cmpxchg("acq", v, old_val, new_val, sizeof(atomic_t)) != old_val);
+	return new_val;
 }
 
 /*

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[David Mosberger]

>>>>> On Fri, 5 Apr 2002 13:40:34 -0800, Gary Hade <garyhade@us.ibm.com> said:

  Gary> asm/atomic.h is not palatable to C++ due to it's use of the
  Gary> C++ keyword "new".

Eh, the kernel is written in C.  If you have an application that
includes a kernel header, fix the application---it's broken.  (This
has been Linus' edict for the last N years, for some N > 3...)

	--david

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[Gary Hade]

On Fri, Apr 05, 2002 at 01:54:27PM -0800, David Mosberger wrote:
> >>>>> On Fri, 5 Apr 2002 13:40:34 -0800, Gary Hade <garyhade@us.ibm.com> said:
> 
>   Gary> asm/atomic.h is not palatable to C++ due to it's use of the
>   Gary> C++ keyword "new".
> 
> Eh, the kernel is written in C.  If you have an application that
> includes a kernel header, fix the application---it's broken.  (This
> has been Linus' edict for the last N years, for some N > 3...)
> 
> 	--david

Oops, I must admit that my gray matter is definitely corrupted by 
working on systems where there was an effort to use #ifdef __KERNEL__ 
to keep all kernel-only code from being included in user-level 
application code.

Would it be okay in the Linux world for an application written 
in C++ to use a system call such as query_module(2)?  If so, the 
application code would include <linux/module.h>.  <linux/module.h>
includes <asm/atomic.h> on a line which is not within an 
#ifdef __KERNEL__ region so the same C++ compile failure will occur.

Gary

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[David Mosberger]

>>>>> On Mon, 8 Apr 2002 09:00:42 -0700, Gary Hade <garyhade@us.ibm.com> said:

  Gary> Would it be okay in the Linux world for an application written
  Gary> in C++ to use a system call such as query_module(2)?

Of course.

  Gary> If so,
  Gary> the application code would include <linux/module.h>.
  Gary> <linux/module.h> includes <asm/atomic.h> on a line which is
  Gary> not within an #ifdef __KERNEL__ region so the same C++ compile
  Gary> failure will occur.

No, glibc needs to provide its own headers for this purpose.

	--david

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Mon, 2002-04-08 at 10:26, David Mosberger wrote:

> No, glibc needs to provide its own headers for this purpose.

Wrong.  If you want this kind of functionality create your own
module-dev package.  It is unfortunate that we have any such header in
glibc butnot changeable.  I certainly will not add more.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[David Mosberger]

>>>>> On 08 Apr 2002 10:51:06 -0700, Ulrich Drepper <drepper@redhat.com> said:

  Uli> On Mon, 2002-04-08 at 10:26, David Mosberger wrote:

  >> No, glibc needs to provide its own headers for this purpose.

  Uli> Wrong.  If you want this kind of functionality create your own
  Uli> module-dev package.  It is unfortunate that we have any such
  Uli> header in glibc butnot changeable.  I certainly will not add
  Uli> more.

So you're OK with glibc providing the syscall stubs for module*(), but
not the header files required to use them?

	--david

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Mon, 2002-04-08 at 12:00, David Mosberger wrote:

> So you're OK with glibc providing the syscall stubs for module*(), but
> not the header files required to use them?

Yes.  There is no fundamental problems with this.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[Gary Hade]

On Mon, Apr 08, 2002 at 01:13:29PM -0700, David Mosberger wrote:
> >>>>> On 08 Apr 2002 12:23:14 -0700, Ulrich Drepper <drepper@redhat.com> said:
> 
>   Uli> On Mon, 2002-04-08 at 12:00, David Mosberger wrote:
>   >> So you're OK with glibc providing the syscall stubs for
>   >> module*(), but not the header files required to use them?
> 
>   Uli> Yes.  There is no fundamental problems with this.
> 
> I guess I don't really see the harm in having glibc provide a header
> for these system call, but as long as the syscall stubs are there,
> it's probably not a huge issue in practice.

David, did you mean to say "... in having glibc not provide ..."?
                                                ^^^
I notice that the *_module(2) man pages which advocate the use of
#include <linux/module.h> are installed as part of the modutils
package.  Is is possibly "modutils" that should provide the header
file that avoids sucking in the possibly problematic kernel-only
code.

Gary

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[David Mosberger]

>>>>> On 08 Apr 2002 12:23:14 -0700, Ulrich Drepper <drepper@redhat.com> said:

  Uli> On Mon, 2002-04-08 at 12:00, David Mosberger wrote:
  >> So you're OK with glibc providing the syscall stubs for
  >> module*(), but not the header files required to use them?

  Uli> Yes.  There is no fundamental problems with this.

I guess I don't really see the harm in having glibc provide a header
for these system call, but as long as the syscall stubs are there,
it's probably not a huge issue in practice.

	--david

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

On Mon, 2002-04-08 at 13:13, David Mosberger wrote:

> I guess I don't really see the harm in having glibc provide a header
> for these system call, but as long as the syscall stubs are there,
> it's probably not a huge issue in practice.

David, you are around long enough to see the dangers.  I don't want to
have any dependencies on the kernel.  Any change in the kernel interface
would force me to make a new release which isn't going to happen.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[David Mosberger]

>>>>> On Mon, 8 Apr 2002 12:33:40 -0700, Gary Hade <garyhade@us.ibm.com> said:

  Gary> David, did you mean to say "... in having glibc not provide
  Gary> ..."?

Nope.  My preference would be for glibc to provide such a header.
Though I see Uli's point about kernel changes.

  Gary> I notice that the *_module(2) man pages which
  Gary> advocate the use of #include <linux/module.h> are installed as
  Gary> part of the modutils package.  Is is possibly "modutils" that
  Gary> should provide the header file that avoids sucking in the
  Gary> possibly problematic kernel-only code.

That certainly would work for me.

	--david

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[Keith Owens]

On Mon, 8 Apr 2002 12:33:40 -0700, 
Gary Hade <garyhade@us.ibm.com> wrote:
>I notice that the *_module(2) man pages which advocate the use of
>#include <linux/module.h> are installed as part of the modutils
>package.  Is is possibly "modutils" that should provide the header
>file that avoids sucking in the possibly problematic kernel-only
>code.

Old man pages (1996).  They date from the time that the kernel and
glibc shared the kernel headers via a symlink.  Linus has changed his
mind since then but the modutils man pages were never updated.

modutils provides include/module.h as part of the source package.  That
file is not installated anywhere, nobody outside modutils has required
it.  If you want to invoke the modutils syscalls yourself, take a copy
of include/module.h from modutils into your source tree.  But don't be
surprised if the interface changes under you.  modutils will know about
any interface changes, other packages will have to cope with the
version skew themselves.

Re: [Linux-ia64] C++ doesn't like asm/atomic.h

[Gary Hade]

On Tue, Apr 09, 2002 at 08:59:50AM +1000, Keith Owens wrote:
> On Mon, 8 Apr 2002 12:33:40 -0700, 
> Gary Hade <garyhade@us.ibm.com> wrote:
> >I notice that the *_module(2) man pages which advocate the use of
> >#include <linux/module.h> are installed as part of the modutils
> >package.  Is is possibly "modutils" that should provide the header
> >file that avoids sucking in the possibly problematic kernel-only
> >code.
> 
> Old man pages (1996).  They date from the time that the kernel and
> glibc shared the kernel headers via a symlink.  Linus has changed his
> mind since then but the modutils man pages were never updated.
> 
> modutils provides include/module.h as part of the source package.  That
> file is not installated anywhere, nobody outside modutils has required
> it.  If you want to invoke the modutils syscalls yourself, take a copy
> of include/module.h from modutils into your source tree.  But don't be
> surprised if the interface changes under you.  modutils will know about
> any interface changes, other packages will have to cope with the
> version skew themselves.

FYI, I am not one of those outside of modutils that intends to use the 
modutils syscalls from either a C or C++ program.  The information in 
the flawed man pages appeared inconsistent with the assertion that code 
in asm/atomic.h is always off-limits to applications.  This prompted 
my questions which are now answered.

David/Ulrich/Keith, Thanks for the very informative discussion.

Gary