Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-06-05 Thread Albert D. Cahalan
Paul Mackerras writes: > The only valid reason for userspace programs to be including kernel > headers is to get definitions that are part of the kernel API. (And > in fact others here will go further and assert that there are *no* > valid reasons for userspace programs to include kernel headers

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-06-05 Thread Paul Mackerras
Adrian Bunk writes: > Whatever the right policy is, the main concern in my initial mail was the > _consistency_ of the kernel headers between different architectures. > So when you want to flush out these programs I see no reason to > inconsistetly change it only on one architecture. Different a

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-06-05 Thread Adrian Bunk
On Tue, 5 Jun 2001, Paul Mackerras wrote: >... > This is why I added #ifdef __KERNEL__ around most of the contents > of include/asm-ppc/*.h. It was done deliberately to flush out those > programs which are depending on kernel headers when they shouldn't. Whatever the right policy is, the main c

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-06-04 Thread Paul Mackerras
Adrian Bunk writes: > (my main concern wasn't whether the "#ifdef __KERNEL__" is correct or not > but I was wondering whether there's a reason why it's different on > different architectures) The only valid reason for userspace programs to be including kernel headers is to get definitions that a

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-06-02 Thread Adrian Bunk
On Wed, 30 May 2001, Ralf Baechle wrote: > > This is no good. The ARM kernel just doesn't provide any atomic primitives > > that will work in user space. If you want atomicity you have to use > > libpthread. > > Similar on some MIPS processors where the kernel has to implement atomic > operatio

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-05-29 Thread Ralf Baechle
On Sun, May 27, 2001 at 11:10:00PM +0100, Philip Blundell wrote: > >--- include/asm-arm/atomic.h.old Sun May 27 22:30:58 2001 > >+++ include/asm-arm/atomic.h Sun May 27 22:58:20 2001 > >@@ -12,6 +12,7 @@ > > * 13-04-1997 RMK Made functions atomic! > > * 07-12-1997 RMK Up

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-05-27 Thread Philip Blundell
>--- include/asm-arm/atomic.h.old Sun May 27 22:30:58 2001 >+++ include/asm-arm/atomic.h Sun May 27 22:58:20 2001 >@@ -12,6 +12,7 @@ > * 13-04-1997 RMK Made functions atomic! > * 07-12-1997 RMK Upgraded for v2.1. > * 26-08-1998 PJB Added #ifdef __KERN

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-05-27 Thread Russell King - ARM Linux
On Sun, May 27, 2001 at 11:07:38PM +0200, Adrian Bunk wrote: > I do also explicitely send this mail to the people that seem to be > responsible for the pieces of code I touch. > > I'm not sure whether the compete removal of the "#ifdef __KERNEL__"'s is > too rude but there are already other archi

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-05-27 Thread Adrian Bunk
On Sun, 27 May 2001, Abramo Bagnara wrote: > Adrian Bunk wrote: > > > > while looking for the reason of a build failure of the ALSA libraries on > > ARM [1] I discovered the following strange thing: > > > > On some architectures a function is inside an "#ifdef __KERNEL__" in the > > header file a

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-05-27 Thread Abramo Bagnara
Adrian Bunk wrote: > > Hi, > > while looking for the reason of a build failure of the ALSA libraries on > ARM [1] I discovered the following strange thing: > > On some architectures a function is inside an "#ifdef __KERNEL__" in the > header file and on others not. Is there a reason for this or

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

2001-05-27 Thread Alan Cox
> On some architectures a function is inside an "#ifdef __KERNEL__" in the > header file and on others not. Is there a reason for this or is this > inconsistency simply a bug? Its probably a bug - primarily it depends if the function is useful when exported to non kernel code - To unsubscribe fro