On Mon, Mar 14, 2022 at 09:19:01AM +0100, Jan Beulich wrote: > On 11.03.2022 15:24, Roger Pau Monné wrote: > > On Mon, Feb 14, 2022 at 10:25:57AM +0100, Jan Beulich wrote: > >> Making adjustments to arbitrarily chosen values shouldn't require > >> auditing the code for possible derived numbers - such a change should > >> be doable in a single place, having an effect on all code depending on > >> that choice. > >> > >> For one make the TDCR write actually use APIC_DIVISOR. With the > >> necessary mask constant introduced, also use that in vLAPIC code. While > >> introducing the constant, drop APIC_TDR_DIV_TMBASE: The bit has been > >> undefined in halfway recent SDM and PM versions. > >> > >> And then introduce a constant tying together the scale used when > >> converting nanoseconds to bus clocks. > >> > >> No functional change intended. > >> > >> Signed-off-by: Jan Beulich <jbeul...@suse.com> > > > > Reviewed-by: Roger Pau Monné <roger....@citrix.com> > > Thanks. > > >> --- > >> I thought we have a generic "glue" macro, but I couldn't find one. Hence > >> I'm (ab)using _AC(). > > > > I would be fine if you want to introduce something right in this > > commit to cover those needs, using _AC is not overly nice (or > > clear) IMO. > > Hmm, I was rather hoping that you (or someone else) would point me > at what I thought I'm overlooking. If anything I'd likely clone > Linux'es __PASTE() (avoiding the leading underscores), but their > placement in linux/compiler_types.h seems pretty arbitrary and > hence not a good guideline for placement in our tree. To be honest > the only thing that would seem halfway consistent to me would be a > separate header, yet that seems somewhat overkill ... Or wait - > maybe xen/lib.h could be viewed as kind of suitable. Of course > there's then the immediate question of whether to make _AC() use > the new macro instead of open-coding it.
I think if possible _AC should be switched to use the new macro, yes. Thanks, Roger.
