From: Ingo Molnar <mingo@kernel.org>
To: "Jürgen Groß" <jgross@suse.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
linux-edac@vger.kernel.org, linux-pm@vger.kernel.org,
linux-hwmon@vger.kernel.org, linux-perf-users@vger.kernel.org,
platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org,
"Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Tony Luck" <tony.luck@intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"Guenter Roeck" <linux@roeck-us.net>,
"Daniel Lezcano" <daniel.lezcano@kernel.org>,
"Zhang Rui" <rui.zhang@intel.com>,
"Lukasz Luba" <lukasz.luba@arm.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>, "Ian Rogers" <irogers@google.com>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"James Clark" <james.clark@linaro.org>,
"Huang Rui" <ray.huang@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Perry Yuan" <perry.yuan@amd.com>,
"K Prateek Nayak" <kprateek.nayak@amd.com>,
"Srinivas Pandruvada" <srinivas.pandruvada@linux.intel.com>,
"Len Brown" <lenb@kernel.org>, "Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Subject: Re: [PATCH 0/8] x86/msr: Drop 32-bit variants of *_on_cpu() MSR functions
Date: Fri, 5 Jun 2026 11:54:23 +0200 [thread overview]
Message-ID: <aiKcz6I8GO-TG8uq@gmail.com> (raw)
In-Reply-To: <b7e799a6-1f1a-49ef-8aac-0d5fd4a06dc7@suse.com>
* Jürgen Groß <jgross@suse.com> wrote:
> > Well, we had a similar discussion back when we standardized on
> > rdmsrq() and wrmsrq(), and we use them as our primary 64-bit
> > MSR handling APIs. Why have a different pattern in any of the
> > derived APIs? It should really use the same conceptual namespace,
> > not some confusing mixture of two naming schemes.
>
> In the long run I'd like to do the same conversion for the rdmsr*() and
> wrmsr*() interfaces, too (so only offering and using the 64-bit variants).
Why? We had this discussion for the original MSR API namespace
cleanup a year ago, and decided to standardize on the rdmsrq()/wrmsrq()
namespace:
c435e608cf59 x86/msr: Rename 'rdmsrl()' to 'rdmsrq()'
78255eb23973 x86/msr: Rename 'wrmsrl()' to 'wrmsrq()'
6fe22abacd40 x86/msr: Rename 'rdmsrl_safe()' to 'rdmsrq_safe()'
6fa17efe4544 x86/msr: Rename 'wrmsrl_safe()' to 'wrmsrq_safe()'
5e404cb7ac4c x86/msr: Rename 'rdmsrl_safe_on_cpu()' to 'rdmsrq_safe_on_cpu()'
27a23a544a55 x86/msr: Rename 'wrmsrl_safe_on_cpu()' to 'wrmsrq_safe_on_cpu()'
d7484babd2c4 x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()'
c895ecdab2e4 x86/msr: Rename 'wrmsrl_on_cpu()' to 'wrmsrq_on_cpu()'
ebe29309c4d2 x86/msr: Rename 'mce_rdmsrl()' to 'mce_rdmsrq()'
8e44e83f57c3 x86/msr: Rename 'mce_wrmsrl()' to 'mce_wrmsrq()'
e2b8af0c6939 x86/msr: Rename 'rdmsrl_amd_safe()' to 'rdmsrq_amd_safe()'
604d15d15ebd x86/msr: Rename 'wrmsrl_amd_safe()' to 'wrmsrq_amd_safe()'
7cbc2ba7c107 x86/msr: Rename 'native_wrmsrl()' to 'native_wrmsrq()'
eef476f15c83 x86/msr: Rename 'wrmsrl_cstar()' to 'wrmsrq_cstar()'
There's several good reasons to use the 'q' suffix in the API names,
why relitigate this? :-)
Thanks,
Ingo
next prev parent reply other threads:[~2026-06-05 9:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 7:08 [PATCH 0/8] x86/msr: Drop 32-bit variants of *_on_cpu() MSR functions Juergen Gross
2026-06-05 7:08 ` [PATCH 2/8] x86/msr: Switch all callers of rdmsrq_on_cpu() to use rdmsr_on_cpu() Juergen Gross
2026-06-05 9:00 ` Ingo Molnar
2026-06-05 7:08 ` [PATCH 3/8] x86/msr: Switch wrmsr_on_cpu() to use a 64-bit quantity Juergen Gross
2026-06-05 7:08 ` [PATCH 6/8] x86/msr: Switch all callers of rdmsrq_safe_on_cpu() to use rdmsr_safe_on_cpu() Juergen Gross
2026-06-05 8:45 ` Ingo Molnar
2026-06-05 9:05 ` [PATCH 0/8] x86/msr: Drop 32-bit variants of *_on_cpu() MSR functions Ingo Molnar
2026-06-05 9:13 ` Jürgen Groß
2026-06-05 9:18 ` Ingo Molnar
2026-06-05 9:40 ` Jürgen Groß
2026-06-05 9:54 ` Ingo Molnar [this message]
2026-06-05 9:56 ` Ingo Molnar
2026-06-05 10:05 ` Jürgen Groß
2026-06-05 10:06 ` Jürgen Groß
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=aiKcz6I8GO-TG8uq@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=daniel.lezcano@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=hansg@kernel.org \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jgross@suse.com \
--cc=jolsa@kernel.org \
--cc=kprateek.nayak@amd.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lukasz.luba@arm.com \
--cc=mario.limonciello@amd.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=perry.yuan@amd.com \
--cc=peterz@infradead.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=ray.huang@amd.com \
--cc=rui.zhang@intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=viresh.kumar@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox