Re: [PATCH v4 3/7] ccid: build smartcard as module

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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.