Re: [libvirt] [RFC PATCHv2 5/5] WIP: smartcard: turn on qemu support
On Mon, Jan 17, 2011 at 01:12:28PM -0700, Eric Blake wrote:
On 01/17/2011 11:42 AM, Alon Levy wrote:
>>> dev: ccid-card-emulated, id ""
>>> dev-prop: backend = "nss-emulated"
>>> dev-prop: cert1 = <null>
>>> dev-prop: cert2 = <null>
>>> dev-prop: cert3 = <null>
>>> dev-prop: db = <null>
>>
>> Hmm - in the hosts-certificates mode, it looks like I need to support an
>> optional <database> sub-element to populate the ccid-card-emulated.db
>> field when desired. Is that field a pathname, a generic arbitrary
>> string, or something else altogether?
>
> Pathname is the only thing I've tested, so let's limit it to this. It's
> NSS specific right now too - but as you see from the arguments it will probably
> be orthogonal, for instance under windows there might be a cryptoapi-emulated
> backend and db argument will be reused.
I think it is pretty easy to add one <smartcard mode=''> per new
backend. The toughest part would be how to query whether a given
backend is available in a given qemu binary, but if you can please make
sure that 'qemu -device usb-ccid,?' lists all valid backends for a given
After looking a little more closely at the implementation (qdev-properties.c,
qdev.h) I think the best way to do this is to add a type called PROP_TYPE_ENUM,
and a callback for the printing - right now there is no callback, i.e. the part
of the equals sign is a static string, not determined in runtime, and even at
compile time to change it requires a new property.
So I could:
1. add a static (compile time) determined list that would appear there, local
change to ccid-card-emulated.c, so easy to see this accepted.
2. send patch adding PROP_TYPE_ENUM with associated callback, not a big patch,
possibly accepted, with the addition that it allows a runtime list to be printed.
It also means doing "-device <somedev>,?" would be running device
specific callback
(doesn't happen right now), I guess that's not a problem.
qemu binary, then we're set (the first two backends of
nss-emulated and
certificates can be assumed if device usb-ccid exists in the first
place). That is:
<smartcard mode='hosts'> gives backend=nss-emulated
<smartcard mode='hosts-certificates'> gives backend=certificates,
cert1-3 are mandatory, and db is optional
and a hypothetical
<smartcard mode='cryptoapi-emulated'> (or some other appropriate name),
along with any appropriate sub-elements, is added later if qemu ever
adds a third valid backend=cryptoapi-emulated
>>> Tell me if this needs to be changed - for instance I could just
>>> reuse the id as the bus name, so it will lose the ".0" suffix.
>>
>> I think keeping the .0 suffix allows you the future ability to support
>> multiple cards on a single bus.
>
> The question was about changing my behavior, since right now I rely on
> the default qemu behavior of appending that ".0". So I understand you
> will supply that as a string bus=<id>.0, and since I actually ignore that
> but qemu computes the same bus id, it will just work.
Sounds reasonable - it should just work for the given setup of limiting
qemu to at most one smartcard (easier to match your current
implementation and expand later), without locking us into place once you
ever do start supporting multiple smartcards.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org