Re: [Qemu-devel] QEMU and Kconfig

[Paolo Bonzini <pbonzini@redhat.com>]

On 09/11/2018 20:16, Eduardo Habkost wrote:
> On Fri, Nov 09, 2018 at 11:10:21AM +0100, Paolo Bonzini wrote:
>> On 08/11/2018 22:00, Eduardo Habkost wrote:
>>> Understood.  My interpretation of "target" was just "a QEMU
>>> binary".  In other words, I thought we were talking about
>>> anything that could be compiled in/out from a specific QEMU
>>> binary.
>>
>> The idea is "target" as opposed to "host".
>>
>>> Do you have a specific reason to restrict the scope to only
>>> guest-visible effects?  Is this just a way to reduce the effort
>>> required for the task, or there are other caveats I'm missing?
>>
>> Because that's what default-configs/ is for---producing
>> config-devices.mak.  IOW it's mostly to reduce the scope, but also
>> because there are differences between config-devices.mak (produced from
>> default-configs/) and config-{host,target}.h (produced by configure).
> 
> I have the impression that the build system has an implicit
> assumption: that any build option that affects only one QEMU
> binary is always guest-visible, and that any build option that is
> not guest visible must affect all built QEMU binaries.  Is this
> going to be always true?

I don't think it's an assumption.  It's more a side effect of avoiding
obj-y unless needed.  Because any build option that affects only one
QEMU binary must use obj-y, and non-guest-visible code generally doesn't
use obj-y, the result is what you say.

Paolo