This "would" conflict with other TLS/TCP changes on list depending on
order of commit, but it does work against the current top. The conflict
would be limited to the new helper qemuDomainGetChardevTLSObjects and
changing the 'if (!cfg->chardevTLS)' to the corresponding 'if
dev->source.data.tcp.haveTLS != VIR_TRISTATE_BOOL_YES)' once Pavel's
changes are in and of course removing the need to fetch 'cfg'. Then
if my other changes related to making 'source' a pointer in the
_virDomainChrDef is accepted, the 'source.' here would change to
'source->'.
Essentially during the review process of adding a secret to access
the TLS environment, it was determined that the backends for redirdev
and rng weren't adding the TLS object on hotplug, even though the
command line processing would add it.
NB: Smartcard would be in the same category, but it doesn't support
hotplug, so we're off the hook for that.
John Ferlan (4):
qemu: Introduce qemuDomainGetChardevTLSObjects for hotplug
qemu: Clean up error path in qemuDomainAttachRedirdevDevice
qemu: Add TLS hotplug for qemuDomainAttachRedirdevDevice
qemu: Add TLS hotplug for qemuDomainAttachRNGDevice
src/qemu/qemu_hotplug.c | 125 ++++++++++++++++++++++++++++++++++++++----------
1 file changed, 99 insertions(+), 26 deletions(-)
--
2.7.4