From: Andi Kleen <ak@muc.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
dmitry.torokhov@gmail.com
Subject: Re: [PATCH] Turn rdmsr, rdtsc into inline functions, clarify names
Date: 6 Aug 2006 05:16:43 +0200
Date: Sun, 6 Aug 2006 05:16:43 +0200 [thread overview]
Message-ID: <20060806031643.GA43490@muc.de> (raw)
In-Reply-To: <1154832963.29151.21.camel@localhost.localdomain>
> 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
next prev parent reply other threads:[~2006-08-06 3:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1154771262.28257.38.camel@localhost.localdomain>
2006-08-06 2:38 ` [PATCH] Turn rdmsr, rdtsc into inline functions, clarify names Andi Kleen
2006-08-06 2:56 ` Rusty Russell
2006-08-06 2:58 ` H. Peter Anvin
2006-08-06 3:09 ` Rusty Russell
2006-08-06 3:11 ` H. Peter Anvin
2006-08-06 3:49 ` Rusty Russell
2006-08-06 3:16 ` Andi Kleen [this message]
2006-08-06 3:52 ` Rusty Russell
2006-08-06 14:58 ` Andi Kleen
2006-08-07 2:43 ` Dmitry Torokhov
2006-08-07 8:48 ` Andi Kleen
2006-08-07 11:09 ` Vojtech Pavlik
2006-08-07 12:28 ` Andi Kleen
2006-08-07 12:48 ` Vojtech Pavlik
2006-08-07 12:56 ` Andi Kleen
2006-08-07 13:18 ` Vojtech Pavlik
2006-08-07 13:32 ` Dmitry Torokhov
2006-08-07 15:01 ` Andi Kleen
2006-08-07 15:19 ` Andreas Mohr
2006-08-07 15:57 ` Andi Kleen
2006-08-07 16:04 ` Vojtech Pavlik
2006-08-07 16:12 ` Andi Kleen
2006-08-07 19:22 ` Vojtech Pavlik
2006-08-14 20:13 ` Pavel Machek
2006-08-07 11:07 ` Vojtech Pavlik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060806031643.GA43490@muc.de \
--to=ak@muc.de \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.