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
