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
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
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
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
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
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
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 are
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
>
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
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 Upgraded
>--- 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
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
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
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
> 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
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
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?
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 from
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 is this
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 and on others
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
--- 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 __KERNEL__
23 matches
Mail list logo
