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
