Messages in this thread | | | Date | 6 Aug 2006 05:16:43 +0200 | Date | Sun, 6 Aug 2006 05:16:43 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH] Turn rdmsr, rdtsc into inline functions, clarify names |
| |
> Please reconsider. This isn't about being pretty, it's about not > having hidden side-effects,
I wouldn't call it hidden, it's well defined in the architecture.
> and having typechecking.
The existing code will already reject any non integer and I don't see a particular need to be more strict than that.
> > If you feel a need to clean up I would suggest you convert more > > users over to the ll variants which take a single 64bit value > > instead of two 32bit ones. > > You mean the l and ll variants? The 64 bit variants are rdmsrl and > rdtscll, not to be confused with rdtscl, which returns the lower 32 > bits. This confusion caused the x86_64 bug in gameport.c
Why does gameport access MSRs or TSCs? That sounds like a bug in itself.
<looking at the code>
This whole thing is broken, e.g. on a preemptive kernel when the code can switch CPUs
Dmitry, I would suggest to convert it over to do_gettimeofday and remove all the architecture ifdefs.
Or maybe just remove it completely. Who cares about the speed of a gameport anyways? And why can't they measure it in user space?
> See why I want to fix these names?
No.
> So if you would prefer u64 rdtsc64(), u32 rdtsc_low(), u64 rdmsr64(int > msr), u32 rdmsr_low(int msr), I can convert everyone to that, although > it's a more invasive change...
I think things are most fine right now, except that I think most users of high low should be converted to work directly on 64bit quantities.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |