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
You meant ccid-card-emulated, right? usb-ccid doesn't have backends. Looking into existing devices, this doesn't look that difficult, It can be printed like so: ccid-card-emulated.backend=nss-emulated/certificates/anythingelse I'll just make sure the names I use don't contains any '/' chars :) Actually, supplying a list of possible backends is easy. Actually testing which are available at runtime - right now it should be identical, since if you can't find the NSS so qemu won't pass the loading stage. But that still means I will report nss-emulated even if there are no hardware devices. Is that acceptable?
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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org