On Thu, May 16, 2024 at 06:13:29PM +0100, Andrew Cooper wrote:
> On 15/05/2024 4:29 pm, Roger Pau Monne wrote:
> > Print the CPU affinity masks as numeric ranges instead of plain hexadecimal
> > bitfields.
> >
> > Signed-off-by: Roger Pau Monné <roger....@citrix.com>
> > ---
> > xen/arch/x86/irq.c | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
> > index 80ba8d9fe912..3b951d81bd6d 100644
> > --- a/xen/arch/x86/irq.c
> > +++ b/xen/arch/x86/irq.c
> > @@ -1934,10 +1934,10 @@ void do_IRQ(struct cpu_user_regs *regs)
> > if ( ~irq < nr_irqs && irq_desc_initialized(desc) )
> > {
> > spin_lock(&desc->lock);
> > - printk("IRQ%d a=%04lx[%04lx,%04lx] v=%02x[%02x] t=%s
> > s=%08x\n",
> > - ~irq, *cpumask_bits(desc->affinity),
> > - *cpumask_bits(desc->arch.cpu_mask),
> > - *cpumask_bits(desc->arch.old_cpu_mask),
> > + printk("IRQ%d a={%*pbl}[{%*pbl},{%*pbl}] v=%02x[%02x]
> > t=%s s=%08x\n",
>
> Looking at this more closely, there's still some information obfuscation
> going on.
>
> How about "... a={} o={} n={} v=..."
>
> so affinity, old and new masks are all stated explicitly, instead of
> having to remember what the square brackets mean, and in particular that
> the masks are backwards?
>
> Happy to adjust on commit.
Sure, I guess I got used to it and didn't think of adjusting the
format. The only risk is anyone having an automated parser to consume
that information, but I think it's unlikely.
Thanks, Roger.
