Re: [PATCH 06/20] x86/msr: Standardize on 'u32' MSR indices in

Ingo Molnar
2025-04-10T06:39:46Z

* Xin Li <xin@zytor.com> wrote:

> On 4/9/2025 8:29 PM, H. Peter Anvin wrote:
> > On April 9, 2025 8:18:12 PM PDT, Xin Li <xin@zytor.com> wrote:
> > > 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);
> > >
> >
> > No, that makes no sense (it would have absolutely no effect.)
> >
>
> For the API definition, yes, it has no effect.
>
> While it makes the API definition more explicit, and its implementations
> for native and Xen would be:
>
> void {native,xen}_write_msr(const u32 msr, const u32 low, const u32 high)
> {
> ....
> }
>
> not worth it at all?

No:

- Using 'const' for input parameter pointers makes sense because it's
easy to have a bug like this in a utility function:

obj_ptr->val = foo;

this has a side effect on the calling context, spreading the local
rot, so to speak, corrupting the object not owned by this function.

- Using 'const' for non-pointer input parameters makes little sense,
because the worst a function can do is to corrupt it locally:

val_high = foo;

... but this bug won't be able to spread via corrupting objects
through a pointer, any bug will be limited to that function.

So neither the kernel, nor any of the major libraries such as glibc
will typically use const for non-pointer function parameters, outside
of very specific exceptions that strengthen the rule.

Thanks,

Ingo