Re: [XEN][PATCH 2/5] x86: hvm: compat: introduce vcpu_is_hcall_compat() helper

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.11.2025 14:07, Grygorii Strashko wrote:
> On 13.11.25 14:22, Jan Beulich wrote:
>> On 11.11.2025 18:54, Grygorii Strashko wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -311,6 +311,15 @@ struct vcpu
>>>   #endif
>>>   };
>>>   
>>> +static inline bool vcpu_is_hcall_compat(const struct vcpu *v)
>>
>> Does the vcpu_ prefix really buy us much here? The per-vCPU aspect is already
>> conveyed by the function parameter, I'd say.
> 
> Such annotation makes it clear that operation is performed on struct vcpu 
> object,
> which improves readability and code analyze (might help also if somebody will 
> ever
> try split sched.h).
> 
> For example:
> 
> is_hcall_compat(curr) in the code doesn't say too much - need parse code
> (or have modern editor which can parse and highlight parameter type for us,
>   still need some mouse manipulations:))

That's one of the reasons we aim at using consistently named variables. "curr"
should be pretty clear to everyone as being "current" latched into a local
variable. Plus of course for every function invocation call site context is
relevant anyway, when it comes to arguments passed to the function.

> vcpu_is_hcall_compat(curr) - is kinda absolutely clear from the first look.
>   
>>
>> Actually - is a parameter in fact needed? It's always current afaics. (Then,
>> if the parameter was to stay for some reason, it would want naming "curr".)
> 
> "curr" it be

My preference would still be is_hcall_compat(void).

Jan