qemu-devel
[Top][All Lists]
Advanced

[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 :)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]