Andy Whitcroft wrote:
It truly is not clear what "type" of thing an __asm__ is these days.
Cirtainly it seems we can use it as an attribute of a type:
register unsigned long __r16 __asm__("$16") = rtc_access->function;
and yet also in its more traditional
On Tue, Jan 29, 2008 at 05:17:28PM -0600, Timur Tabi wrote:
> checkpatch.pl thinks that __asm__ is a function name, so it complains about
> a space between the function name and a parenthesis when it sees
> "__asm__ ("mov ax,bx")".
>
> This change will also e
On Tue, Jan 29, 2008 at 05:17:28PM -0600, Timur Tabi wrote:
checkpatch.pl thinks that __asm__ is a function name, so it complains about
a space between the function name and a parenthesis when it sees
__asm__ (mov ax,bx).
This change will also encourage developers to use '__asm__' instead
Andy Whitcroft wrote:
It truly is not clear what type of thing an __asm__ is these days.
Cirtainly it seems we can use it as an attribute of a type:
register unsigned long __r16 __asm__($16) = rtc_access-function;
and yet also in its more traditional form:
__asm__( call foo
checkpatch.pl thinks that __asm__ is a function name, so it complains about
a space between the function name and a parenthesis when it sees
"__asm__ ("mov ax,bx")".
This change will also encourage developers to use '__asm__' instead of 'asm'.
Signed-off-by: Timur Ta
checkpatch.pl thinks that __asm__ is a function name, so it complains about
a space between the function name and a parenthesis when it sees
__asm__ (mov ax,bx).
This change will also encourage developers to use '__asm__' instead of 'asm'.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
scripts
On Mon, 2007-07-23 at 23:30 +0200, Andi Kleen wrote:
> > gcc also tries to count the number of instructions, to guess how large in
> > bytes the asm block is, as it could make a difference for near vs short
> > jumps, etc.
>
> Are you sure? I doubt it. It would need a full asm parser to do this
>
> gcc also tries to count the number of instructions, to guess how large in
> bytes the asm block is, as it could make a difference for near vs short
> jumps, etc.
Are you sure? I doubt it. It would need a full asm parser to do this
properly and then even it could be wrong
(e.g. when the
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Trent Piepho wrote:
> > gcc also tries to count the number of instructions, to guess how large in
> > bytes the asm block is, as it could make a difference for near vs short
> > jumps, etc.
> >
>
> How does it do that? By looking for \n, ';', etc?
Trent Piepho wrote:
> gcc also tries to count the number of instructions, to guess how large in
> bytes the asm block is, as it could make a difference for near vs short
> jumps, etc.
>
How does it do that? By looking for \n, ';', etc?
J
-
To unsubscribe from this list: send the line
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Satyam Sharma wrote:
> > The (3) as I had originally written / meant was that multiple
> > instructions in a volatile asm would not get _individually_
> > interspersed with the rest of the code i.e. be emitted out
> > _consecutively_. I don't think
Satyam Sharma wrote:
> The (3) as I had originally written / meant was that multiple
> instructions in a volatile asm would not get _individually_
> interspersed with the rest of the code i.e. be emitted out
> _consecutively_. I don't think we need any such guarantees for
> the non-atomic variants
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> I'm not quite sure what your point is.
Could be a case of terminology confusion ...
> The paragraph you quoted is
> pretty explicit in saying that volatile doesn't prevent an "asm
> volatile" from being interspersed with other code, and the
Satyam Sharma wrote:
> Hi Jeremy,
>
>
> On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
>
>
>> Satyam Sharma wrote:
>>
>>> From: Satyam Sharma <[EMAIL PROTECTED]>
>>>
>>> [7/8] i386: bitops: Kill needless usage of __a
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in this file. The
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in t
Satyam Sharma wrote:
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
>
> Another oddity I noticed in this file. The semantics of __volatile__
> when used to qualify inline __asm__ are that the compiler wil
BTW if you want to optimize inline asm code a bit -- find_first_bit /
find_first_zero_bit / for_each_cpu could really benefit from a optimized
version
for cpumask_t sized bitmaps. That would save a lot of cycles in some of the
hotter paths of the kernel like the scheduler.
-Andi
-
To
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
> [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
>
> Another oddity I noticed in this file. The semantics of __volatile__
> when used to qualify inline __asm
From: Satyam Sharma <[EMAIL PROTECTED]>
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or, (3) interspers
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or, (3) intersperse, our inline
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler
BTW if you want to optimize inline asm code a bit -- find_first_bit /
find_first_zero_bit / for_each_cpu could really benefit from a optimized
version
for cpumask_t sized bitmaps. That would save a lot of cycles in some of the
hotter paths of the kernel like the scheduler.
-Andi
-
To
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline
Satyam Sharma wrote:
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
I'm not quite sure what your point is.
Could be a case of terminology confusion ...
The paragraph you quoted is
pretty explicit in saying that volatile doesn't prevent an asm
volatile from being interspersed with other code, and the example
Satyam Sharma wrote:
The (3) as I had originally written / meant was that multiple
instructions in a volatile asm would not get _individually_
interspersed with the rest of the code i.e. be emitted out
_consecutively_. I don't think we need any such guarantees for
the non-atomic variants of
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
The (3) as I had originally written / meant was that multiple
instructions in a volatile asm would not get _individually_
interspersed with the rest of the code i.e. be emitted out
_consecutively_. I don't think we need
Trent Piepho wrote:
gcc also tries to count the number of instructions, to guess how large in
bytes the asm block is, as it could make a difference for near vs short
jumps, etc.
How does it do that? By looking for \n, ';', etc?
J
-
To unsubscribe from this list: send the line
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Trent Piepho wrote:
gcc also tries to count the number of instructions, to guess how large in
bytes the asm block is, as it could make a difference for near vs short
jumps, etc.
How does it do that? By looking for \n, ';', etc?
Yes:
gcc also tries to count the number of instructions, to guess how large in
bytes the asm block is, as it could make a difference for near vs short
jumps, etc.
Are you sure? I doubt it. It would need a full asm parser to do this
properly and then even it could be wrong
(e.g. when the sections
On Mon, 2007-07-23 at 23:30 +0200, Andi Kleen wrote:
gcc also tries to count the number of instructions, to guess how large in
bytes the asm block is, as it could make a difference for near vs short
jumps, etc.
Are you sure? I doubt it. It would need a full asm parser to do this
properly
Mike Frysinger wrote:
> On Wednesday 20 June 2007, H. Peter Anvin wrote:
>> Andi Kleen wrote:
asm-i386/msr.h should not be exported to userspace at all, it contains
nothing but kernel-internal helpers.
>>> Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
>>> very
On Wednesday 20 June 2007, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> asm-i386/msr.h should not be exported to userspace at all, it contains
> >> nothing but kernel-internal helpers.
> >
> > Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
> > very useful in user space
On Wednesday 20 June 2007, H. Peter Anvin wrote:
Andi Kleen wrote:
asm-i386/msr.h should not be exported to userspace at all, it contains
nothing but kernel-internal helpers.
Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
very useful in user space if you know
Mike Frysinger wrote:
On Wednesday 20 June 2007, H. Peter Anvin wrote:
Andi Kleen wrote:
asm-i386/msr.h should not be exported to userspace at all, it contains
nothing but kernel-internal helpers.
Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
very useful in user
Andi Kleen wrote:
>> asm-i386/msr.h should not be exported to userspace at all, it contains
>> nothing but kernel-internal helpers.
>
> Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
> very
> useful in user space if you know what you're doing. Unfortunately a lot of
Andi Kleen wrote:
asm-i386/msr.h should not be exported to userspace at all, it contains
nothing but kernel-internal helpers.
Actually rdtsc and rdtscll and potentially rdpmc which is in there can be
very
useful in user space if you know what you're doing. Unfortunately a lot of
its
On Mon, Jun 18, 2007 at 09:00:09PM +0200, Sam Ravnborg wrote:
> Do you imply that if we see asm or __asm__ in user space headers we ougth
> to warn about it?
> Seems at least sensible to me but if we introduce such a check we should
> kill all offenders first - which Mike's p
On Mon, Jun 18, 2007 at 07:34:50PM +0100, Christoph Hellwig wrote:
> On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
> > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > headers can be used with gcc's -std=c99.
>
> We should not
> asm-i386/msr.h should not be exported to userspace at all, it contains
> nothing but kernel-internal helpers.
Actually rdtsc and rdtscll and potentially rdpmc which is in there can be very
useful in user space if you know what you're doing. Unfortunately a lot of its
users don't,
but not
On Mon, Jun 18, 2007 at 07:34:50PM +0100, Christoph Hellwig wrote:
> On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
> > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > headers can be used with gcc's -std=c99.
>
> We should not
On Mon, Jun 18, 2007 at 02:19:10AM -0400, Mike Frysinger wrote:
> Since asm-ia64/gcc_intrin.h gets exported to userspace, we need to make sure
> to use __asm__() rather than asm() since the latter is not available when
> compiling with gcc with GNU extensions turned off (like
On Mon, Jun 18, 2007 at 10:02:21AM -0400, Mike Frysinger wrote:
> > This is wrong for two reasons:
> >
> > - MSRs are not accessible in user space.
> > - .section .fixup is not applicable to user space.
> >
> > Anything MSR-related should be protected by __KERNEL__ instead.
> >
> > This NAK
On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
> This changes asm() to __asm__() and volatile to __volatile__ so that these
> headers can be used with gcc's -std=c99.
We should not allow inline assemly in the exported part of userspace headers
at all. These headers mus
On Monday 18 June 2007, Christoph Hellwig wrote:
> On Mon, Jun 18, 2007 at 01:24:24AM +0200, Arnd Bergmann wrote:
> > On Monday 18 June 2007, Arjan van de Ven wrote:
> > > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > > This changes asm() to __asm__(
On Mon, Jun 18, 2007 at 08:27:15AM -0600, Robert Hancock wrote:
> If we expect userspace apps to include them, then I would vote for no,
> not for anything outside of #ifdef __KERNEL__ in exported headers. Keep
> in mind also that C++ apps may need to include these as well and those
>
On Mon, Jun 18, 2007 at 01:24:24AM +0200, Arnd Bergmann wrote:
> On Monday 18 June 2007, Arjan van de Ven wrote:
> >
> > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > &g
Robert Hancock wrote:
>
> If we expect userspace apps to include them, then I would vote for no,
> not for anything outside of #ifdef __KERNEL__ in exported headers. Keep
> in mind also that C++ apps may need to include these as well and those
> extensions don't always play well in C++ mode.
David Woodhouse wrote:
On Mon, 2007-06-18 at 01:24 +0200, Arnd Bergmann wrote:
On Monday 18 June 2007, Arjan van de Ven wrote:
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's
On Monday 18 June 2007, H. Peter Anvin wrote:
> Mike Frysinger wrote:
> > Most of the macros in msr.h already use __asm__ and __volatile__, this
> > patch brings the rest into line. This is needed since these get exported
> > into userspace (need to use strict __asm__ vs
On Mon, 2007-06-18 at 01:24 +0200, Arnd Bergmann wrote:
> On Monday 18 June 2007, Arjan van de Ven wrote:
> >
> > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > > header
On Mon, Jun 18, 2007 at 10:15:18AM +0200, Martin Schwidefsky wrote:
> On Mon, 2007-06-18 at 09:36 +0200, Heiko Carstens wrote:
> > Hmm.. spka is a sort of priviledged instruction and shouldn't be
> > user space visible.
> > I will move it so it's under #ifdef __KERNEL__.
>
> Yes, I think this is
On Mon, 2007-06-18 at 09:36 +0200, Heiko Carstens wrote:
> Hmm.. spka is a sort of priviledged instruction and shouldn't be
> user space visible.
> I will move it so it's under #ifdef __KERNEL__.
Yes, I think this is better. On a side node, why did we add psw_set_key
to ptrace.h? processor.h
On Monday 18 June 2007, Sam Ravnborg wrote:
> On Sun, Jun 17, 2007 at 06:54:24PM -0400, Mike Frysinger wrote:
> > This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> > rejecting them in favor of __asm__() in exported headers.
>
> I have a new version
On Sun, Jun 17, 2007 at 06:54:24PM -0400, Mike Frysinger wrote:
> This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> rejecting them in favor of __asm__() in exported headers.
Hi Mike.
I have a new version of hdrcheck in works written in perl
and a bit faster too.
Mike Frysinger wrote:
> Most of the macros in msr.h already use __asm__ and __volatile__, this patch
> brings the rest into line. This is needed since these get exported into
> userspace (need to use strict __asm__ vs asm when gcc compiles with GNU
> extensions turned off).
> -
On Mon, Jun 18, 2007 at 02:23:06AM -0400, Mike Frysinger wrote:
> Since asm-s390/ptrace.h is exported to userspace, we need to make sure we use
> __asm__() rather than asm() as the latter is disabled when gcc compiles with
> GNU extensions turned off (like -std=c99).
>
> Sign
On 6/18/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Mon, 18 Jun 2007 01:17:46 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Monday 18 June 2007, Andrew Morton wrote:
> > And does the kernel pass these checks?
>
> nope ... should i audit the arches before this gets merged ?
Yes
Since asm-s390/ptrace.h is exported to userspace, we need to make sure we use
__asm__() rather than asm() as the latter is disabled when gcc compiles with
GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-s390/ptra
Since asm-ia64/gcc_intrin.h gets exported to userspace, we need to make sure
to use __asm__() rather than asm() since the latter is not available when
compiling with gcc with GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/inclu
Most of the macros in msr.h already use __asm__ and __volatile__, this patch
brings the rest into line. This is needed since these get exported into
userspace (need to use strict __asm__ vs asm when gcc compiles with GNU
extensions turned off).
Signed-off-by: Mike Frysinger <[EMAIL PROTEC
Most of the macros in msr.h already use __asm__ and __volatile__, this patch
brings the rest into line. This is needed since these get exported into
userspace (need to use strict __asm__ vs asm when gcc compiles with GNU
extensions turned off).
Signed-off-by: Mike Frysinger [EMAIL PROTECTED
Since asm-ia64/gcc_intrin.h gets exported to userspace, we need to make sure
to use __asm__() rather than asm() since the latter is not available when
compiling with gcc with GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm
Since asm-s390/ptrace.h is exported to userspace, we need to make sure we use
__asm__() rather than asm() as the latter is disabled when gcc compiles with
GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-s390/ptrace.h b
On 6/18/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 18 Jun 2007 01:17:46 -0400 Mike Frysinger [EMAIL PROTECTED] wrote:
On Monday 18 June 2007, Andrew Morton wrote:
And does the kernel pass these checks?
nope ... should i audit the arches before this gets merged ?
Yes please. I'd
Mike Frysinger wrote:
Most of the macros in msr.h already use __asm__ and __volatile__, this patch
brings the rest into line. This is needed since these get exported into
userspace (need to use strict __asm__ vs asm when gcc compiles with GNU
extensions turned off).
---
diff --git a/include
On Mon, Jun 18, 2007 at 02:23:06AM -0400, Mike Frysinger wrote:
Since asm-s390/ptrace.h is exported to userspace, we need to make sure we use
__asm__() rather than asm() as the latter is disabled when gcc compiles with
GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger
On Sun, Jun 17, 2007 at 06:54:24PM -0400, Mike Frysinger wrote:
This updates scripts/hdrschecks.sh by grepping for asm() constructs and
rejecting them in favor of __asm__() in exported headers.
Hi Mike.
I have a new version of hdrcheck in works written in perl
and a bit faster too.
I hope
On Monday 18 June 2007, Sam Ravnborg wrote:
On Sun, Jun 17, 2007 at 06:54:24PM -0400, Mike Frysinger wrote:
This updates scripts/hdrschecks.sh by grepping for asm() constructs and
rejecting them in favor of __asm__() in exported headers.
I have a new version of hdrcheck in works written
On Mon, 2007-06-18 at 09:36 +0200, Heiko Carstens wrote:
Hmm.. spka is a sort of priviledged instruction and shouldn't be
user space visible.
I will move it so it's under #ifdef __KERNEL__.
Yes, I think this is better. On a side node, why did we add psw_set_key
to ptrace.h? processor.h would
On Mon, Jun 18, 2007 at 10:15:18AM +0200, Martin Schwidefsky wrote:
On Mon, 2007-06-18 at 09:36 +0200, Heiko Carstens wrote:
Hmm.. spka is a sort of priviledged instruction and shouldn't be
user space visible.
I will move it so it's under #ifdef __KERNEL__.
Yes, I think this is better.
On Mon, 2007-06-18 at 01:24 +0200, Arnd Bergmann wrote:
On Monday 18 June 2007, Arjan van de Ven wrote:
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99.
hmm
On Monday 18 June 2007, H. Peter Anvin wrote:
Mike Frysinger wrote:
Most of the macros in msr.h already use __asm__ and __volatile__, this
patch brings the rest into line. This is needed since these get exported
into userspace (need to use strict __asm__ vs asm when gcc compiles with
GNU
David Woodhouse wrote:
On Mon, 2007-06-18 at 01:24 +0200, Arnd Bergmann wrote:
On Monday 18 June 2007, Arjan van de Ven wrote:
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's
Robert Hancock wrote:
If we expect userspace apps to include them, then I would vote for no,
not for anything outside of #ifdef __KERNEL__ in exported headers. Keep
in mind also that C++ apps may need to include these as well and those
extensions don't always play well in C++ mode. (Last
On Mon, Jun 18, 2007 at 01:24:24AM +0200, Arnd Bergmann wrote:
On Monday 18 June 2007, Arjan van de Ven wrote:
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99
On Mon, Jun 18, 2007 at 08:27:15AM -0600, Robert Hancock wrote:
If we expect userspace apps to include them, then I would vote for no,
not for anything outside of #ifdef __KERNEL__ in exported headers. Keep
in mind also that C++ apps may need to include these as well and those
extensions
On Monday 18 June 2007, Christoph Hellwig wrote:
On Mon, Jun 18, 2007 at 01:24:24AM +0200, Arnd Bergmann wrote:
On Monday 18 June 2007, Arjan van de Ven wrote:
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so
On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99.
We should not allow inline assemly in the exported part of userspace headers
at all. These headers must only
On Mon, Jun 18, 2007 at 10:02:21AM -0400, Mike Frysinger wrote:
This is wrong for two reasons:
- MSRs are not accessible in user space.
- .section .fixup is not applicable to user space.
Anything MSR-related should be protected by __KERNEL__ instead.
This NAK doesn't apply to
On Mon, Jun 18, 2007 at 02:19:10AM -0400, Mike Frysinger wrote:
Since asm-ia64/gcc_intrin.h gets exported to userspace, we need to make sure
to use __asm__() rather than asm() since the latter is not available when
compiling with gcc with GNU extensions turned off (like -std=c99).
This header
On Mon, Jun 18, 2007 at 07:34:50PM +0100, Christoph Hellwig wrote:
On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99.
We should not allow inline assemly
asm-i386/msr.h should not be exported to userspace at all, it contains
nothing but kernel-internal helpers.
Actually rdtsc and rdtscll and potentially rdpmc which is in there can be very
useful in user space if you know what you're doing. Unfortunately a lot of its
users don't,
but not
On Mon, Jun 18, 2007 at 07:34:50PM +0100, Christoph Hellwig wrote:
On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99.
We should not allow inline assemly
On Mon, Jun 18, 2007 at 09:00:09PM +0200, Sam Ravnborg wrote:
Do you imply that if we see asm or __asm__ in user space headers we ougth
to warn about it?
Seems at least sensible to me but if we introduce such a check we should
kill all offenders first - which Mike's patches seems to trigger
On Monday 18 June 2007, Andrew Morton wrote:
> Also, your changelog sucks:
>
> This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> rejecting them in favor of __asm__() in exported headers.
>
> well OK. But for what reason? We can see a lot of
t; > This updates scripts/hdrschecks.sh by grepping for asm() constructs
> > > > and rejecting them in favor of __asm__() in exported headers.
> > >
> > > And does the kernel pass these checks?
> >
> > nope ... should i audit the arches before this gets merg
grepping for asm() constructs and
> > > rejecting them in favor of __asm__() in exported headers.
> >
> > And does the kernel pass these checks?
>
> nope ... should i audit the arches before this gets merged ?
Yes please. I'd rather not break things in this fashion: it causes a st
On Monday 18 June 2007, Andrew Morton wrote:
> On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> > rejecting them in favor of __asm__() in exported headers.
>
&g
On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote:
> This updates scripts/hdrschecks.sh by grepping for asm() constructs and
> rejecting them in favor of __asm__() in exported headers.
And does the kernel pass these checks? Which architectures have
On Sunday 17 June 2007, Arnd Bergmann wrote:
> On Monday 18 June 2007, Arjan van de Ven wrote:
> > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > This changes asm() to __asm__() and volatile to __volatile__ so that
> > > these headers can be used with
On Monday 18 June 2007, Arjan van de Ven wrote:
>
> On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > headers can be used with gcc's -std=c99.
>
> hmm but the kernel doesn't use -s
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> This changes asm() to __asm__() and volatile to __volatile__ so that these
> headers can be used with gcc's -std=c99.
hmm but the kernel doesn't use -std=c99...
-
To unsubscribe from this list: send the line "unsubscribe l
This updates scripts/hdrschecks.sh by grepping for asm() constructs and
rejecting them in favor of __asm__() in exported headers.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/scripts/hdrcheck.sh b/scripts/hdrcheck.sh
index 3159858..33d17cc 100755
--- a/scripts/hdrch
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-arm/byteorder.h b/include/asm-arm/byteorder.h
index e6f7fcd..39105dc 100644
--- a/include/a
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
---
diff --git a/include/asm-arm/byteorder.h b/include/asm-arm/byteorder.h
index e6f7fcd..39105dc 100644
--- a/include/asm-arm
On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
This changes asm() to __asm__() and volatile to __volatile__ so that these
headers can be used with gcc's -std=c99.
hmm but the kernel doesn't use -std=c99...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
1 - 100 of 118 matches
Mail list logo
