On 08.08.2019 11:45, Andrew Cooper wrote: > On 08/08/2019 10:08, Jan Beulich wrote: >> On 08.08.2019 10:33, Andrew Cooper wrote: >>> On 08/08/2019 05:50, Juergen Gross wrote: >>>> On 07.08.19 20:11, Andrew Cooper wrote: >>>>> <snip> >>>>> Its not exactly the easiest to dump to follow. >>>>> >>>>> First of all - I don't see why the hold/block time are printed like >>>>> that. It >>>>> might be a holdover from the 32bit build, pre PRId64 support. They >>>>> should >>>>> probably use PRI_stime anyway. >>>> Fine with me. >>>> >>>>> The domid rendering is unfortunate. Ideally we'd use %pd but that would >>>>> involve rearranging the logic to get a struct domain* in hand. >>>>> Seeing as >>>>> you're the last person to modify this code, how hard would that be to >>>>> do? >>>> It would completely break the struct type agnostic design. >>> Ok. As an alternatively, how about %pdr which takes a raw domid? It >>> would be a trivial adjustment in the vsnprintf code, and could plausibly >>> be useful elsewhere where we have a domid and not a domain pointer. >> At the risk of upsetting / annoying you: > > Yes you really have > >> A domid_t would again >> better be formatted via %od (and without the need to take the >> address of a respective variable). In the case here it would >> have the minor additional benefit of conserving on format string >> length. > > There are concrete reasons why it is a terrible idea, because none of > this has anything to do with octal, and that %od has a well defined > meaning which is not related to domid's.
I'm curious to learn what well defined meaning %od has. > There is also a very good > reason why all the magic is hidden behind one single formatter. > > You seem hell bent on making it actively confusing and complicated to > write and read printk()'s, and I am not willing to lumber anyone > developing on Xen with this cognitive complexity. > > I am stick to death of having the same over and over, so let me stop any > further wasting of time and be absolutely crystal clear. > > NACK to any form of overloading %o In which case, if I took a similar position for the PCI SBDF formatting using %pp, we'd be in a dead end. Waste of time or not - while you have made crystal clear why you personally dislike overloading %o, afaic you've not provided any non-subjective (i.e. truly technical) reasons, which would be what might help convince me of sticking to just %p overloading. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
