On 03.08.2023 03:51, Stefano Stabellini wrote:
> On Wed, 2 Aug 2023, Nicola Vetrini wrote:
>> --- a/xen/arch/x86/hvm/mtrr.c
>> +++ b/xen/arch/x86/hvm/mtrr.c
>> @@ -687,13 +687,13 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d,
>> uint64_t gfn_start,
>>
>> static int cf_check hvm_save_mtrr_msr(struct vcpu *v, hvm_domain_context_t
>> *h)
>> {
>> - const struct mtrr_state *mtrr_state = &v->arch.hvm.mtrr;
>> + const struct mtrr_state *mtrr = &v->arch.hvm.mtrr;
>
> I can see in hvm_vcpu_cacheattr_init, mtrr_get_type and other places
> that we use:
>
> const struct mtrr_state *m
>
> maybe that's better? I'll let Jan comment.
When unambiguous, personally I prefer shorter names (and as you say
existing code supports me in that). Obviously the longer a function,
the more potential future ambiguities also need taking into
consideration.
Jan
