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

[Anthony Liguori]

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