Re: [libvirt] [RFC PATCHv2 5/5] WIP: smartcard: turn on qemu support
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)