[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4813BED5.7070000@zytor.com>
Date: Sat, 26 Apr 2008 16:46:29 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: dean gaudet <dean@...tic.org>
CC: Erik Bosman <ejbosman@...vu.nl>,
Michael Kerrisk <mtk.manpages@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Andrea Arcangeli <andrea@...share.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 2/3] x86: Implement prctl PR_GET_TSC and PR_SET_TSC
dean gaudet wrote:
> On Sat, 26 Apr 2008, H. Peter Anvin wrote:
>
>> dean gaudet wrote:
>>> i might be too late... but shouldn't these #defines be PR_SET_RDTSC and
>>> PR_GET_RDTSC or something like that?
>>>
>>> to me calling them PR_SET_TSC/PR_GET_TSC just seem like alternative ways to
>>> change/get the TSC (and could even reduce to portable TSC implementations...
>>> since such registers do exist on other architectures).
>>>
>> I would argue no, the flag is "is the TSC available". RDTSC is an
>> x86-specific name and would map poorly onto other architectures.
>
> yeah but "SET TSC" to me reads as "set the TSC".... i read nothing about
> making some instruction available or not.
>
> although clock_gettime/clock_settime could more natural APIs for such
> things.
>
PR_SET/PR_GET are the common prefixes, though.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists