Re: [Xen-devel] [PATCH 2/4] x86: misc printk() adjustments

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/12/15 14:48, Jan Beulich wrote:
>>>> On 21.12.15 at 15:41, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 21/12/15 14:34, Jan Beulich wrote:
>>> --- a/xen/arch/x86/io_apic.c
>>> +++ b/xen/arch/x86/io_apic.c
>>> @@ -2310,13 +2310,14 @@ int ioapic_guest_read(unsigned long phys
>>>      return 0;
>>>  }
>>>  
>>> -#define WARN_BOGUS_WRITE(f, a...)                                       \
>>> -    dprintk(XENLOG_INFO, "\n%s: "                                        \
>>> -            "apic=%d, pin=%d, irq=%d\n"                 \
>>> -            "%s: new_entry=%08x\n"                      \
>>> -            "%s: " f, __FUNCTION__, apic, pin, irq,        \
>>> -            __FUNCTION__, *(u32 *)&rte,           \
>>> -            __FUNCTION__ , ##a )
>>> +#define WARN_BOGUS_WRITE(f, a...)                       \
>>> +    dprintk(XENLOG_INFO, "\n"                           \
>>> +            XENLOG_INFO "%s: apic=%d, pin=%d, irq=%d\n" \
>>> +            XENLOG_INFO "%s: new_entry=%08x\n"          \
>>> +            XENLOG_INFO "%s: " f "\n",                  \
>>> +            __func__, apic, pin, irq,                   \
>>> +            __func__, *(u32 *)&rte,                     \
>>> +            __func__, ##a )
>>>  
>>>  int ioapic_guest_write(unsigned long physbase, unsigned int reg, u32 val)
>>>  {
>>> @@ -2388,7 +2389,7 @@ int ioapic_guest_write(unsigned long phy
>>>          rte.vector = desc->arch.vector;
>>>          if ( *(u32*)&rte != ret )
>>>              WARN_BOGUS_WRITE("old_entry=%08x pirq=%d\n%s: "
>>> -                             "Attempt to modify IO-APIC pin for in-use 
>>> IRQ!\n",
>>> +                             "Attempt to modify IO-APIC pin for in-use 
>>> IRQ!",
>>>                               ret, pirq, __FUNCTION__);
>> Given that this is the sole user of WARN_BOGUS_WRITE(), I would
>> recommend folding it all together in a simple dprintk(), and remove some
>> of the redundant information, and fixing the resulting message to take
>> up fewer lines.
> If you feel strongly about this I could certainly do so, but I did
> consider that option and decided against it to retain the option
> of using the macro (again?) in a second place.

I don't forsee it being useful to use again.

Either way, Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel