Re: [PATCH] KVM: arm64: Avoid naming collision in tracing

[Vincent Donnefort <vdonnefort@google.com>]

[...]

> >
> > > > I did not add Fixes tag as this is currently dormant and not breaking
> > > > anything.
> > > > ---
> > > >  arch/arm64/kvm/hyp/include/nvhe/clock.h | 8 ++++----
> > > >  arch/arm64/kvm/hyp/nvhe/clock.c         | 4 ++--
> > > >  arch/arm64/kvm/hyp/nvhe/trace.c         | 4 ++--
> > > >  3 files changed, 8 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/kvm/hyp/include/nvhe/clock.h b/arch/arm64/kvm/hyp/include/nvhe/clock.h
> > > > index 9f429f5c0664..c2ccd0e8bf22 100644
> > > > --- a/arch/arm64/kvm/hyp/include/nvhe/clock.h
> > > > +++ b/arch/arm64/kvm/hyp/include/nvhe/clock.h
> > > > @@ -6,11 +6,11 @@
> > > >  #include <asm/kvm_hyp.h>
> > > >
> > > >  #ifdef CONFIG_NVHE_EL2_TRACING
> > > > -void trace_clock_update(u32 mult, u32 shift, u64 epoch_ns, u64 epoch_cyc);
> > > > -u64 trace_clock(void);
> > > > +void hyp_trace_clock_update(u32 mult, u32 shift, u64 epoch_ns, u64 epoch_cyc);
> > > > +u64 hyp_trace_clock(void);
> > >
> > > hyp_trace_clock overlaps the host side: arch/arm64/kvm/hyp_trace.c
> > > already has a struct hyp_trace_clock and static helpers
> > > hyp_trace_clock_enable() / hyp_trace_clock_show() for the debugfs view
> > > of the same clock. No actual collision, so this is only a readability
> > > point, but a reader grepping hyp_trace_clock now gets two unrelated
> > > things. Maybe you'd want to consider a different name, but naming is
> > > hard :)

If we were to rename: the clock is a "hyp_clock" so probably trace_hyp_clock()
is the right thing here.

while the "hyp_trace_" is the prefix for hyp_trace.c file content.

Although I would like to see why we pull trace_clock() from the kernel into EL2.
That bit sounds wrong and if we have a way around perhaps that's better?

> >
> > Yes, that shouldn't be a problem,  I just added hyp_ prefix, but I
> > am ok with any suggestions!
> 
> Didn't I say naming is hard? :) How about, el2_? Not really happy with
> that either tbh... but can't think of a better one...
> 
> /fuad
> 
> >
> > Thanks,
> > Mostafa
> >
> > >
> > > Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
> > > Tested-by: Fuad Tabba < fuad.tabba@linux.dev>
> > >
> > > Test: builds fine with the different config enables.
> > >
> > > Cheers,
> > > /fuad