Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-07-22 Thread H. Peter Anvin
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-07-22 Thread Mike Frysinger
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-07-22 Thread Mike Frysinger
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-07-22 Thread H. Peter Anvin
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-20 Thread H. Peter Anvin
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-20 Thread H. Peter Anvin
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread Andi Kleen
> 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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread Christoph Hellwig
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread Mike Frysinger
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread H. Peter Anvin
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

[patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread Mike Frysinger
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]>

[patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread Mike Frysinger
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] ---

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread H. Peter Anvin
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread Mike Frysinger
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread Christoph Hellwig
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

Re: [patch] use __asm__ and __volatile__ in asm-x86_64/msr.h

2007-06-18 Thread Andi Kleen
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