qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] hw/ppc/spapr_rng: Introduce CONFIG_SPAPR_RNG


From: Philippe Mathieu-Daudé
Subject: Re: [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>



reply via email to

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