On Tue, Jun 30, 2020 at 06:07:51PM +0200, Gerd Hoffmann wrote:
> > >> 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.
>
> [ note: v5 of the series does this ]
>
> > > 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.
>
> Looks challenging on a quick glance ...
Yeah, I'm not convinced modularizing that is a good use of time. It is
plumbed in across multiple backends (chardev, migration, block, ui)
and also providing the secure RNG used across QEMU.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
