Re: [XEN PATCH 1/6] x86: rename variable 'e820' to address MISRA C:2012 Rule 5.3

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 7 Aug 2023, Jan Beulich wrote:
> On 04.08.2023 17:27, Nicola Vetrini wrote:
> > The variable declared in the header file 'xen/arch/x86/include/asm/e820.h'
> > is shadowed by many function parameters, so it is renamed to avoid these
> > violations.
> > 
> > No functional changes.
> > 
> > Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
> > ---
> > This patch is similar to other renames done on previous patches, and the
> > preferred strategy there was to rename the global variable. This one
> > has more occurrences that are spread in various files, but
> > the general pattern is the same.
> 
> Still I think it would be better done the other way around, and perhaps in
> more than a single patch. It looks like "many == 3", i.e.
> - e820_add_range(), which is only ever called with "e820" as its argument,
>   and hence the parameter could be dropped,
> - e820_change_range_type(), which is in the same situation, and
> - reserve_e820_ram(), which wants its parameter renamed.

Let me premise that this is x86 code and I am happy with whatever you
prefer.

I would like to point out that renaming the global var is a lot safer as
a change than renaming the local var. That is because renaming the
global, if you forget one invocation it won't compile (now of course it
can still happen for an optional feature like tboot, but in general
you'll catch everything with a compilation). If you rename the local and
you missed a rename, it will change the behavior of the code as it will
fall back to the global and compile without issues.

So I think it would be best to rename the global when possible.


> Alternatively, if we really were to change the name of the global, we'd
> want to take a more complete approach: Right now we have e820_raw[],
> boot_e820[], and e820[]. We'd want them to follow a uniform naming scheme
> then (e820_ first or _e820 last), with the other part of the name suitably
> describing the purpose (which "map" doesn't do).

I would go with this option