Re: [Qemu-devel] QEMU and Kconfig

[Eduardo Habkost]

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?


> 
> In particular, config-host.h and config-target.h are header files, but
> config-devices.mak is not because the same file is linked into multiple
> QEMU binaries that can and will enable different devices.  The only way
> to use a hypothetical config-devices.h would be to move its users from
> common-obj-y to obj-y.

Yeah, I wouldn't want to move things to obj-y.  I would prefer to
make kconfig affect only makefile variables (not header files and
macros).

-- 
Eduardo