Re: [RFC PATCH 2/3] misra: address rule 5.5 gnttab

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/07/2025 10:24 pm, Dmytro Prokopchuk1 wrote:
> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
> ---
>  xen/common/grant_table.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index cf131c43a1..9b8f0d87d3 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -127,8 +127,8 @@ static void __init cf_check 
> max_maptrack_frames_init(struct param_hypfs *par)
>                        opt_max_maptrack_frames_val);
>  }
>  #else
> -#define update_gnttab_par(v, unused1, unused2)     update_gnttab_par(v)
> -#define parse_gnttab_limit(a, v, unused1, unused2) parse_gnttab_limit(a, v)
> +#define UPDATE_GNTTAB_PAR(v, unused1, unused2)     update_gnttab_par(v)
> +#define PARSE_GNTTAB_LIMIT(a, v, unused1, unused2) parse_gnttab_limit(a, v)

I'm afraid this doesn't compile, and cannot be taken in this form. 
CONFIG_HYPFS very intentionally uses this macro alias to discard the 2nd
and 3rd parameters.

Also, it's really not just gnttab which suffers from this.  All
subsystems with mutable parameters follow the same pattern.

I don't have a good suggestion, and it's extra awkward that the MISRA
violation only occurs in the !CONFIG_HYPFS case which is trying to stub
out the logic with minimal #ifdef-ary.  It is definitely weird and
unergonomic for par and parval to not even be evaluated, but that's
necessary for things to compile.

~Andrew