[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 redhat com    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
> 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]