[libvirt] [Qemu-devel] [PATCH 00/16] usb-ccid (v18)
Alon Levy
alevy at redhat.com
Mon Feb 7 18:00:57 UTC 2011
On Mon, Feb 07, 2011 at 08:56:30AM -0700, Eric Blake wrote:
> [adding libvir-list as well]
>
> On 02/07/2011 08:44 AM, Alon Levy wrote:
> >>> I guess I'll wait a little longer for more feedback? Should I split
> >>> the enum property separately? it's only used by ccid-card-emualted atm.
> >>
> >> The only non-cosmetic concern I have about your series is the enum
> >> property so I would strongly suggest splitting it. If you did that
> >> for v19, it will be pretty close to merge ready.
> >>
> >
> > Eric,
> >
> > How does this affect libvirt? could you assume a default set of backends
> > if "-device ccid-card-emulated,?" returns "backend=string" instead of
> > "backend=A/B" ?
>
> Hmm. At the moment, libvirt only looks for "ccid-card-emulated" in the
> -device ? list, and hasn't yet tried inspecting -device
> ccid-card-emulated,? output. In short, libvirt assumes that the
> presence of ccid-card-emulated implies that both modes are available
> (libvirt's <smartcard mode='host'/> => backend=nss-emulated; <smartcard
> mode='host-certificates' => backend=certificates). Is it possible for
> qemu to have support for one, but not both, of those modes? If that's
> the case, then supporting "backend=nss-emulated/certificates" in -device
> ccid-card-emulated,? would be handy for libvirt (for example, it would
> be just "backend=certificates" if nss-emulated is not available). But
> if it's an all-or-none approach (all backends are available if
> ccid-card-emulated is present), then libvirt's current code won't be
> impacted by changing the string to the simpler "backend=string".
>
So turns out this was not actually required (except as a measure to
spart a discussion on enums). Since right now it is all or nothing as you
say, there is no immediate need for this, so I'll just drop it, and when
a QMP solution materialized I can use it.
> --
> Eric Blake eblake at redhat.com +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>
More information about the libvir-list
mailing list