[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4/5] print: introduce a format specifier for pci_sbdf_t



>>> On 24.05.19 at 12:59, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 24/05/2019 11:36, Jan Beulich wrote:
>>>>> On 10.05.19 at 18:10, <roger.pau@xxxxxxxxxx> wrote:
>>> The new format specifier is '%pp', and prints a pci_sbdf_t using the
>>> seg:bus:dev.func format. Replace all SBDFs printed using
>>> '%04x:%02x:%02x.%u' to use the new format specifier.
>> So on the positive side Linux doesn't use 'p' yet, so we're only at risk
>> of a future conflict. However, having to pass a 64-bit pointer just
>> to print a 32-bit entity seems rather wasteful to me. Since we can't
>> use entirely new format specifiers, did you consider (ab)using one
>> we rarely use, like %o, suffixed similarly like we do for %p? The
>> extension could be restricted to apply only when neither field width
>> nor precision nor any flags were specified, i.e. only to plain %o (at
>> least initially).
>>
>> We'd then have something along the lines of
>>
>> #define PRI_sbdf "op"
>> #define PRI_SBDF(v) ((v).sbdf)
>>
>> and
>>
>>     printk("%" PRI_sbdf ": ...\n", PRI_SBDF(pdev->sbdf), ...);
> 
> Except the answer will be the same as every time you've asked this in
> the past.

I don't recall suggesting any use of %o so far. The one thing I
do recall suggesting (and which turned out bad) was using an
l modifier with %pb.

> No, because -Wformat doesn't tolerate it.

How would -Wformat choke here? %o accepts (unsigned) integers,
doesn't it?

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.