Re: [PATCH 0/8] x86/msr: Drop 32-bit variants of *_on_cpu() MSR functions

[Ingo Molnar <mingo@kernel.org>]

* Ingo Molnar <mingo@kernel.org> wrote:

> 
> * 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? :-)

And just to be clear: I have no objections whatsoever to
phasing out all the old 32-bit APIs, like your series does.

Thanks,

	Ingo