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 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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list