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@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