[Xen-devel] printf formatter for pci_sbdf_t

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] printf formatter for pci_sbdf_t
Date: Wed, 17 Jul 2019 16:08:10 +0200	[thread overview]
Message-ID: <20190717140810.a5a4bhmm7fb6oah5@Air-de-Roger.citrite.net> (raw)

Hello,

As part of some PCI related cleanup I'm doing, which includes
expanding the usage of pci_sbdf_t, I'm also planning to add a custom
printf formatter for pci_sbdf_t [0], so that a SBDF can be printed
without having to specify four formatters (and pass four parameters)
each time (%04x:%02x:%02x.%u).

There's been some debate on the previous version about whether the
formatter should be %pp or %op, and I would like to settle on one of
them before sending a new version:

Using %pp pros:
 - Xen already overloads p with other custom implementations.

Using %pp cons:
 - Passes a pointer (which is always 64b on x86) to store a
   32bit value (SBDF).
 - Requires a dereference to access the value.

Using %op pros:
 - Can pass a 32bit integer naturally.

Using %op cons:
 - No other overloads of the o specifier exists so far, either in Xen
   or in Linux AFAIK.

My first implementation used %pp because it's inline with the current
overloads already present, and printk not being performance critical I
don't see much problem in using 64bit to pass a 32bit value, or in
requiring a dereference to access it. We could keep using %pp and
casting the sbdf value to 'void *' to avoid the dereference, but I
don't think there's much value on doing that, the more that call sites
would need to use a macro to hide the casting away.

Anyway, I would like to get some consensus on which path to follow,
either %pp or %op before sending a new version of the series. I'm
Ccing both Andrew and Jan as they had strong opinions, and I would
personally vote for %pp as I've expressed above, but don't mind
implementing something else as long as there's consensus and it's not
going to get stuck on an endless argument.

Thanks, Roger.

[0] https://patchew.org/Xen/20190510161056.48648-1-roger.pau@citrix.com/20190510161056.48648-5-roger.pau@citrix.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel