[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH v2] hw/ppc/spapr_rng: Introduce CONFI
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [PATCH v2] hw/ppc/spapr_rng: Introduce CONFIG_SPAPR_RNG switch for spapr_rng.c |
Date: |
Tue, 9 Oct 2018 15:58:05 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 |
On 09/10/2018 15:27, Thomas Huth wrote:
> On 2018-10-09 13:45, Philippe Mathieu-Daudé wrote:
>> Hi Thomas,
>>
>> On 08/10/2018 14:39, Thomas Huth wrote:
>>> The spapr-rng device is suboptimal when compared to virtio-rng, so
>>> users might want to disable it in their builds. Thus let's introduce
>>> a proper CONFIG switch to allow us to compile QEMU without this device.
>>> The function spapr_rng_populate_dt is required for linking, so move it
>>> to a different location.
>>
>> Without CONFIG_SPAPR_RNG this function is not reachable, can you use a
>> stub instead?
>
> I'd like to avoid stubs if possible. stubs are fine if there is no easy
> other solution, but they are a little bit confusing ("which of these
> functions is now linked into the executable?"), so in case there is no
> urgent need, it's IMHO way nicer to get along without them. In this
> case, there is no real urgent need - the function is just small, and
> does not have any other dependencies into the disabled code, so why
> should we complicate things here and introduce a stub?
In this case this is fair enough because this function uses the same API
than the surrounding functions (no extra headers/libs required).
[I just read v1 comments on this series]
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>