On 02/07/2011 09:56 AM, 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).
Why is libvirt assuming anything about a feature that isn't in upstream
QEMU?
Regards,
Anthony Liguori
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".
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list