On 10/5/20 3:22 PM, Daniel P. Berrangé wrote:
> On Mon, Oct 05, 2020 at 12:54:40PM +0200, Philippe Mathieu-Daudé wrote:
>> While the FW_CFG_DATA_GENERATOR_INTERFACE is only consumed
>> by a device only available using system-mode (fw_cfg), it is
>> implemented by a crypto component (tls-cipher-suites) which
>> is always available when crypto is used.
>>
>> Commit 69699f3055 introduced the following error in the
>> qemu-storage-daemon binary:
>>
>> $ echo -e \
>> '{"execute": "qmp_capabilities"}\r\n{"execute":
>> "qom-list-types"}\r\n{"execute": "quit"}\r\n' \
>> | storage-daemon/qemu-storage-daemon --chardev stdio,id=qmp0 --monitor
>> qmp0
>> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 5},
>> "package": ""}, "capabilities": ["oob"]}}
>> {"return": {}}
>> missing interface 'fw_cfg-data-generator' for object 'tls-creds'
>> Aborted (core dumped)
>>
>> Since QOM dependencies are resolved at runtime, this issue
>> could not be triggered at linktime, and we don't have test
>> running the qemu-storage-daemon binary.
>>
>> Fix by always registering the QOM interface.
>>
>> Reported-by: Kevin Wolf <kw...@redhat.com>
>> Fixes: 69699f3055 ("crypto/tls-cipher-suites: Produce fw_cfg consumable
>> blob")
>> Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com>
>> ---
>> I first used:
>>
>> +if config_host.has_key('CONFIG_GNUTLS') or have_system
>> + qom_ss.add(files('fw_cfg_interface.c'))
>> +endif
>>
>> but then realized anything could implement a QOM interface,
>> so better keep this generic.
>> ---
>> hw/nvram/fw_cfg.c | 7 -------
>> qom/fw_cfg_interface.c | 15 +++++++++++++++
>
> I feel this should be left in hw/nvram, but still added to qom_ss.
>
> The code location should reflect the functional area and maintainership,
> so we shouldn't move code just to satisfy linkage problems.
I thought Meson would conditionally include subdir() meson.build
like the Makefile based previous buildsys, but I was wrong, all
subdir are processed.
I'll respin with your suggestion, thanks.
Phil.
