[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |