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

[Gerd Hoffmann]

  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.

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

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?

take care,
  Gerd