On 6/23/20 7:12 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> + { .type = "ccid-card-passthru", .mod = "usb-smartcard" },
>>> + { .type = "ccid-card-emulated", .mod = "usb-smartcard" },
>>
>> We want to use type definitions here (such TYPE_CCID_PASSTHRU),
>> as we don't guaranty them stable.
>
> Hmm? I'm pretty sure '-device ccid-card-passthru' *is* stable ABI.
Asking on IRC, there is no explicit contract.
But as you remarked, doing so would break the CLI, so we should
some day clarify that objects implementing TYPE_USER_CREATABLE
can not have their typename changed. For the rest, there is no
restriction.
>> Since there is a relation between QOM type and the module,
>> can we store/use the module name in the TypeInfo declaration?
>>
>> static const TypeInfo passthru_card_info = {
>> .name = TYPE_CCID_PASSTHRU,
>> .parent = TYPE_CCID_CARD,
>> .instance_size = sizeof(PassthruState),
>> .class_init = passthru_class_initfn,
>> .module_name = "usb-smartcard", <=====
>> };
>
> That doesn't buy us much, the TypeInfo ends up in the module not qemu.
> So qemu can't access it without loading the module.
>
> We do *not* want load all modules on startup though. Which means we
> need a such list in qemu. The struct above is just that. There
> certainly is room for improvement, building that list automatically
> somehow for example.
OK.
> Given that most devices don't depend on external shared libraries I
> expect the list of device modules will stay relatively short. So I've
> decided to start with something simple and see how it goes (see also
> patch 1/7).
>
>> Actually this modularization is not specific to QDEV
>> and can be used to all QOM right? I.e:
>>
>> static const TypeInfo qcrypto_tls_creds_x509_info = {
>> .parent = TYPE_QCRYPTO_TLS_CREDS,
>> .name = TYPE_QCRYPTO_TLS_CREDS_X509,
>> .module_name = "gnu-tls",
>> ...
>> }
>
> Not as-is. You'll need module load hooks in more places then and some
> code tweaks to move it from qdev level (loading hw-* module only) to qom
> level.
>
> But, yes, moving the infrastructure to some qom-module.c file might be
> useful when modularizing non-device objects. Do you have any candidates
> in mind?
So far I was only thinking of gnutls.
