From: Andi Kleen <andi@firstfloor.org>
To: "H. Peter Anvin" <hpa@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [1/3] Provide rdtscll() asm/msr.h for user space
Date: Wed, 8 Oct 2008 01:11:49 +0200 [thread overview]
Message-ID: <20081007231149.GT20740@one.firstfloor.org> (raw)
In-Reply-To: <48EBD555.9060104@kernel.org>
On Tue, Oct 07, 2008 at 02:32:05PM -0700, H. Peter Anvin wrote:
> I really don't think this belongs in the kernel. It's not even a case
> of "usable by accident" anymore, and hasn't worked for a while, so it's
> not a matter of legacy, either.
Actually it that's not true because most distros still use relatively old kernel
includes. It really only broke with paravirt, which especially on 64bit
is extremly new.
I think on a few of the latest distros actually break it in their
default setup, that is why I looked at fixing it (ran into this
in suse 11.0, in 10.3 it was all still ok)
>
> Mixing fundamentally unrelated kernel and userspace variants of the same
> function just makes the aggregation uglier than both.
I disagree on the fundamentally unrelated. They are the same semantically
(although the paravirt entry point is misnamed, it shouldn't call
itself RDTSC)
>
> (Also, most userspace variants I have seen have what the kernel calls
> "rdtscll" and calls it "rdtsc".)
At least asm/msr.h has used it like this forever (2.4).
> I would suggest writing a <sys/tsc.h> header file and submitting to the
> glibc people, instead, or perhaps even better, start a libarch/libx86 tree.
That wouldn't work on old kernels. asm/msr.h has been the traditional
interface for this and rdtsc has worked forever (at least dating back to 2.0)
rdtscll is a bit newer, but still in Linux terms ancient (2.4)
Also in my experience distributions are extremly slow at keeping up
with glibc, so even if this was added to glibc it would be probably
years before it would be actually usable :/ And I see about zero
point in changing a perfectly fine include name breaking everything old.
Anyways if you insist I can probably deal without
but I (and likely others) would think something nasty about you every time
I have to cut'n'paste that code again. Do you really want to risk that? @)
-Andi
--
ak@linux.intel.com
next prev parent reply other threads:[~2008-10-07 23:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-07 11:43 [PATCH] [1/3] Provide rdtscll() asm/msr.h for user space Andi Kleen
2008-10-07 11:43 ` [PATCH] [2/3] Use the fancy DECLARE_EAX_EDX macros for rdtscp too Andi Kleen
2008-10-07 11:43 ` [PATCH] [3/3] Remove unused EAX_EDX_ARGS Andi Kleen
2008-10-07 21:32 ` [PATCH] [1/3] Provide rdtscll() asm/msr.h for user space H. Peter Anvin
2008-10-07 23:11 ` Andi Kleen [this message]
2008-10-07 23:25 ` H. Peter Anvin
2008-10-07 23:37 ` Andi Kleen
2008-10-07 23:45 ` H. Peter Anvin
2008-10-07 23:42 ` [PATCH] [1/3] Provide rdtscll() asm/msr.h for user space II Andi Kleen
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=20081007231149.GT20740@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=hpa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/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.