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).
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.
Paolo
