[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 08/19] aspeed/timer: Fix behaviour running Linux
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH 08/19] aspeed/timer: Fix behaviour running Linux |
Date: |
Wed, 27 Sep 2023 08:46:47 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Cédric Le Goater <clg@kaod.org> writes:
> On 9/27/23 04:12, Joel Stanley wrote:
>> On Fri, 22 Sept 2023 at 13:21, Cédric Le Goater <clg@kaod.org> wrote:
>>
>>>> + t->start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>>>> + return calculate_time(t, MAX(MAX(t->match[0], t->match[1]), 0));
>>>
>>> This MAX(MAX(x, y), 0) looks strange to me. Would you remember where it
>>> comes
>>> from ? Thanks,
>> That looks very strange. I think you've sorted it, so I wanted to
>> bring up the MAX macros themselves. It's unfortunate that they create
>> a non-unique local variable. Are we allowed to borrow the kernels
>> macros? They have some infrastructure for creating a unique local
>> variable name, as well as handling the const and non-const variants
>> with the one macro.
>> https://elixir.bootlin.com/linux/v6.5/source/include/linux/minmax.h
>
> I believe that's what Markus does in its own way :
>
>
> 20230921121312.1301864-8-armbru@redhat.com/">https://lore.kernel.org/qemu-devel/20230921121312.1301864-8-armbru@redhat.com/
I wasn't aware of the kernel's infrastructure. We can steal it if
people think it provides additional value. Make your case :)