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