From: Xin Li <xin@zytor.com>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>,
Dave Hansen <dave.hansen@intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 06/20] x86/msr: Standardize on 'u32' MSR indices in <asm/msr.h>
Date: Wed, 9 Apr 2025 20:18:12 -0700 [thread overview]
Message-ID: <63ab3ea9-c55d-48d2-8344-fb4314baf240@zytor.com> (raw)
In-Reply-To: <9c014962-d4cb-4e68-be15-efbe2ea26531@zytor.com>
On 4/9/2025 6:37 PM, H. Peter Anvin wrote:
> On 4/9/25 14:55, Xin Li wrote:
>>
>> It looks to me that we don't use the "const" qualifier in the code a
>> lot. However since the MSR index is usually not expected to change
>> inside the MSR API implementations, would it be nicer to add the "const"
>> qualifier?
>>
>> The same to the MSR value of MSR write APIs.
>>
>
> "const" on an automatic variable (including function arguments) is
> usually not very meaningful, unless it is manifest as a memory object
> (see below.)
>
> Personally I tend to use "const" anyway in more complex functions to
> make it clear that a variable is not expected to change while in scope
> (and I also prefer to reduce the scope of a variable as much as
> possible), but for a simple function like this it is more clutter than
> anything else.
Good point!
A question NOT related to this patch set, the MSR write API prototype
defined in struct pv_cpu_ops as:
void (*write_msr)(unsigned int msr, unsigned low, unsigned high);
Will it be better to add "const" to its arguments? I.e.,
void (*write_msr)(const u32 msr, const u32 low, const u32 high);
> Now, "const" on a *memory object* (pointer target) is a very different
> thing and should in general be used where ever writing to an object is
> not going to happen.
>
> An automatic variable becomes manifest as a memory object if its address
> is taken anywhere in its scope (using the & operator or an unindexed
> array) and the address of that pointer stored. The last part means that
> the compiler (if it is is smart enough) can take a sequence of
> operations equivalent to *& and eliminate it.
>
> Keep in mind that, for C (not necessarily C++):
>
> 1. in *all* cases "foo[x]" is exactly equivalent to "*(foo + x)"
> 2. *if* "foo" is declared as an array type, then "foo" is exactly
> equivalent to "&foo[0]".
>
> "const" in C a little less strict than you would like; the only way in C
> before C23 to declare a "true" constant is using enum or a #define macro
> (which of course pollutes the global namespace). In block scope it
> usually doesn't matter for scalar types and const or static const will
> work just fine, but it is only in C23 than C imported "constexpr" from
> C++ (which has had it since C++11.)
Nice to know.
Thanks!
Xin
next prev parent reply other threads:[~2025-04-10 3:18 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 20:28 [PATCH 00/20] x86 MSR in-kernel API type cleanup and rename Ingo Molnar
2025-04-09 20:28 ` [PATCH 01/20] x86/msr: Standardize on u64 in <asm/msr.h> Ingo Molnar
2025-04-09 20:28 ` [PATCH 02/20] x86/msr: Standardize on u64 in <asm/msr-index.h> Ingo Molnar
2025-04-09 20:28 ` [PATCH 03/20] x86/msr: Use u64 in rdmsrl_amd_safe() and wrmsrl_amd_safe() Ingo Molnar
2025-04-09 20:28 ` [PATCH 04/20] x86/msr: Use u64 in rdmsrl_safe() and paravirt_read_pmc() Ingo Molnar
2025-04-09 20:28 ` [PATCH 05/20] x86/msr: Harmonize the prototype and definition of do_trace_rdpmc() Ingo Molnar
2025-04-09 20:28 ` [PATCH 06/20] x86/msr: Standardize on 'u32' MSR indices in <asm/msr.h> Ingo Molnar
2025-04-09 21:55 ` Xin Li
2025-04-10 1:37 ` H. Peter Anvin
2025-04-10 3:18 ` Xin Li [this message]
2025-04-10 3:29 ` H. Peter Anvin
2025-04-10 3:53 ` Xin Li
2025-04-10 6:14 ` H. Peter Anvin
2025-04-10 6:34 ` Xin Li
2025-04-10 6:36 ` H. Peter Anvin
2025-04-10 7:48 ` Peter Zijlstra
2025-04-10 8:53 ` H. Peter Anvin
2025-04-10 17:45 ` Xin Li
2025-04-10 6:39 ` Ingo Molnar
2025-04-10 6:52 ` Xin Li
2025-04-10 7:00 ` H. Peter Anvin
2025-04-09 20:28 ` [PATCH 07/20] x86/msr: Rename 'rdmsrl()' to 'rdmsrq()' Ingo Molnar
2025-04-09 20:28 ` [PATCH 08/20] x86/msr: Rename 'wrmsrl()' to 'wrmsrq()' Ingo Molnar
2025-04-09 20:28 ` [PATCH 09/20] x86/msr: Rename 'rdmsrl_safe()' to 'rdmsrq_safe()' Ingo Molnar
2025-04-09 20:28 ` [PATCH 10/20] x86/msr: Rename 'wrmsrl_safe()' to 'wrmsrq_safe()' Ingo Molnar
2025-04-09 20:28 ` [PATCH 11/20] x86/msr: Rename 'rdmsrl_safe_on_cpu()' to 'rdmsrq_safe_on_cpu()' Ingo Molnar
2025-04-09 20:28 ` [PATCH 12/20] x86/msr: Rename 'wrmsrl_safe_on_cpu()' to 'wrmsrq_safe_on_cpu()' Ingo Molnar
2025-04-09 20:29 ` [PATCH 13/20] x86/msr: Rename 'rdmsrl_on_cpu()' to 'rdmsrq_on_cpu()' Ingo Molnar
2025-04-09 20:29 ` [PATCH 14/20] x86/msr: Rename 'wrmsrl_on_cpu()' to 'wrmsrq_on_cpu()' Ingo Molnar
2025-04-09 20:29 ` [PATCH 15/20] x86/msr: Rename 'mce_rdmsrl()' to 'mce_rdmsrq()' Ingo Molnar
2025-04-09 20:29 ` [PATCH 16/20] x86/msr: Rename 'mce_wrmsrl()' to 'mce_wrmsrq()' Ingo Molnar
2025-04-09 20:29 ` [PATCH 17/20] x86/msr: Rename 'rdmsrl_amd_safe()' to 'rdmsrq_amd_safe()' Ingo Molnar
2025-04-09 20:29 ` [PATCH 18/20] x86/msr: Rename 'wrmsrl_amd_safe()' to 'wrmsrq_amd_safe()' Ingo Molnar
2025-04-09 20:29 ` [PATCH 19/20] x86/msr: Rename 'native_wrmsrl()' to 'native_wrmsrq()' Ingo Molnar
2025-04-09 20:29 ` [PATCH 20/20] x86/msr: Rename 'wrmsrl_cstar()' to 'wrmsrq_cstar()' Ingo Molnar
2025-04-10 7:31 ` [PATCH 00/20] x86 MSR in-kernel API type cleanup and rename Peter Zijlstra
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=63ab3ea9-c55d-48d2-8344-fb4314baf240@zytor.com \
--to=xin@zytor.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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
all inboxes | Powered by JetHome®