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
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
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
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
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
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
>--- 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
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
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
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
> 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
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 is this
inconsistency simply a bug?
12 matches
Mail list logo
