[libvirt] [Qemu-devel] [PATCH 00/16] usb-ccid (v18)

Eric Blake eblake at redhat.com
Mon Feb 7 15:56:30 UTC 2011


[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".

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110207/578524cd/attachment-0001.sig>


More information about the libvir-list mailing list