From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: dinechin@redhat.com, "Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org, "Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH v4 3/7] ccid: build smartcard as module
Date: Tue, 30 Jun 2020 17:24:10 +0100 [thread overview]
Message-ID: <20200630162410.GB1370404@redhat.com> (raw)
In-Reply-To: <20200630160751.y52htbwik4ppurlx@sirius.home.kraxel.org>
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 :|
next prev parent reply other threads:[~2020-06-30 16:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 13:55 [PATCH v4 0/7] build some devices as modules Gerd Hoffmann
2020-06-22 13:55 ` [PATCH v4 1/7] qdev: add support for device module loading Gerd Hoffmann
2020-06-26 18:46 ` Richard Henderson
2020-06-22 13:55 ` [PATCH v4 2/7] build: fix device module builds Gerd Hoffmann
2020-06-22 13:55 ` [PATCH v4 3/7] ccid: build smartcard as module Gerd Hoffmann
2020-06-23 15:28 ` Philippe Mathieu-Daudé
2020-06-23 17:12 ` Gerd Hoffmann
2020-06-30 9:44 ` Philippe Mathieu-Daudé
2020-06-30 16:07 ` Gerd Hoffmann
2020-06-30 16:24 ` Daniel P. Berrangé [this message]
2020-06-22 13:55 ` [PATCH v4 4/7] usb: build usb-redir " Gerd Hoffmann
2020-06-22 13:55 ` [PATCH v4 5/7] vga: build qxl " Gerd Hoffmann
2020-06-22 13:56 ` [PATCH v4 6/7] vga: build virtio-gpu only once Gerd Hoffmann
2020-06-22 13:56 ` [PATCH v4 7/7] vga: build virtio-gpu as module Gerd Hoffmann
2020-06-23 15:04 ` [PATCH v4 0/7] build some devices as modules Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200630162410.GB1370404@redhat.com \
--to=berrange@redhat.com \
--cc=dinechin@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.