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

Re: [Xen-devel] [PATCH 0/4] enhance lock debugging

  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Thu, 8 Aug 2019 11:51:13 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=suse.com;dmarc=pass action=none header.from=suse.com;dkim=pass header.d=suse.com;arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9GI7F5p8Hux2bQBlaXIuppTRv7HCfoENffhdApyoUk8=; b=KLVcdWMT8MARh9aAo8pdJgT3lu3aqx88Q270rRs7DUEIieIe5X5qnVBlcpMv/3vqfitBZdI6C6ghgCxbBe0ddwecSgcVMH9obB+k9W0BRxNI/xCm8KPyn/jYDJ0/QG5UL+DVt8sguPGnTo8RQ1rnkheFfDT406iZSPEv5XNtdaAJ4GNdKGkdwS0ROtPY0lmQt86qAm3/e8qPEaIVzCi7U02HuVp5IkGVmDs/QXxgOOhINKRYRxmeJjBe8BreAc67sSgtk0czouJ9Y4/MgoKWo6h3vo8KrRzAwOasCn836ThAWPLPXmwLFpkA7PKEnA0Er3O/16cmlioydfqzV32Hbw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dNXWVGxwOgqsizZ+F1Z5q26mgrIegsAQYTVwlgQirIgr/UawZeOGP0gXnI4mA8rkC+pNUPhetxERnwLvVMD72fQIWdr5nWy+YxvL/SSBjoYXGPqjoyM9AQzZmTWM74HYLpCM2Jx+o8uFPI7/Dt8N8qCiFiS2MzCi/7ZOp6uUSE4nD98gb+a3+sOraItZZ89ApEwz7Gw7KBtbJ3tQFi9XaeSfHKB2mEbzwWaX0MYV2y9P3RWfR8TlBUELG3E2gZjVeuSKJyCwG0DEP6i3QRBz6j0kyyQCqoeWLsf0LwEA0XvThj16dDwJJEe6/rQuln8tU7//lAd+akzeMBhjCOdLZw==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Juergen Gross <JGross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, WeiLiu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 08 Aug 2019 11:52:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVTaTjLrtftDrvKkCKqSelFkELw6bw7JlBgAAJ1oCAAApms4AAIwSA
  • Thread-topic: [PATCH 0/4] enhance lock debugging

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.

Xen-devel mailing list



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