Re: [libvirt] [Qemu-devel] [PATCH 00/16] usb-ccid (v18)
[adding libvir-list as well] On 02/07/2011 08:44 AM, Alon Levy wrote:
I guess I'll wait a little longer for more feedback? Should I split the enum property separately? it's only used by ccid-card-emualted atm.
The only non-cosmetic concern I have about your series is the enum property so I would strongly suggest splitting it. If you did that for v19, it will be pretty close to merge ready.
Eric,
How does this affect libvirt? could you assume a default set of backends if "-device ccid-card-emulated,?" returns "backend=string" instead of "backend=A/B" ?
Hmm. At the moment, libvirt only looks for "ccid-card-emulated" in the -device ? list, and hasn't yet tried inspecting -device ccid-card-emulated,? output. In short, libvirt assumes that the presence of ccid-card-emulated implies that both modes are available (libvirt's <smartcard mode='host'/> => backend=nss-emulated; <smartcard mode='host-certificates' => backend=certificates). Is it possible for qemu to have support for one, but not both, of those modes? If that's the case, then supporting "backend=nss-emulated/certificates" in -device ccid-card-emulated,? would be handy for libvirt (for example, it would be just "backend=certificates" if nss-emulated is not available). But if it's an all-or-none approach (all backends are available if ccid-card-emulated is present), then libvirt's current code won't be impacted by changing the string to the simpler "backend=string". -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Mon, Feb 07, 2011 at 08:56:30AM -0700, Eric Blake wrote:
[adding libvir-list as well]
On 02/07/2011 08:44 AM, Alon Levy wrote:
I guess I'll wait a little longer for more feedback? Should I split the enum property separately? it's only used by ccid-card-emualted atm.
The only non-cosmetic concern I have about your series is the enum property so I would strongly suggest splitting it. If you did that for v19, it will be pretty close to merge ready.
Eric,
How does this affect libvirt? could you assume a default set of backends if "-device ccid-card-emulated,?" returns "backend=string" instead of "backend=A/B" ?
Hmm. At the moment, libvirt only looks for "ccid-card-emulated" in the -device ? list, and hasn't yet tried inspecting -device ccid-card-emulated,? output. In short, libvirt assumes that the presence of ccid-card-emulated implies that both modes are available (libvirt's <smartcard mode='host'/> => backend=nss-emulated; <smartcard mode='host-certificates' => backend=certificates). Is it possible for qemu to have support for one, but not both, of those modes? If that's the case, then supporting "backend=nss-emulated/certificates" in -device ccid-card-emulated,? would be handy for libvirt (for example, it would be just "backend=certificates" if nss-emulated is not available). But if it's an all-or-none approach (all backends are available if ccid-card-emulated is present), then libvirt's current code won't be impacted by changing the string to the simpler "backend=string".
So turns out this was not actually required (except as a measure to spart a discussion on enums). Since right now it is all or nothing as you say, there is no immediate need for this, so I'll just drop it, and when a QMP solution materialized I can use it.
-- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On 02/07/2011 09:56 AM, Eric Blake wrote:
[adding libvir-list as well]
On 02/07/2011 08:44 AM, Alon Levy wrote:
I guess I'll wait a little longer for more feedback? Should I split the enum property separately? it's only used by ccid-card-emualted atm.
The only non-cosmetic concern I have about your series is the enum property so I would strongly suggest splitting it. If you did that for v19, it will be pretty close to merge ready.
Eric,
How does this affect libvirt? could you assume a default set of backends if "-device ccid-card-emulated,?" returns "backend=string" instead of "backend=A/B" ?
Hmm. At the moment, libvirt only looks for "ccid-card-emulated" in the -device ? list, and hasn't yet tried inspecting -device ccid-card-emulated,? output. In short, libvirt assumes that the presence of ccid-card-emulated implies that both modes are available (libvirt's<smartcard mode='host'/> => backend=nss-emulated;<smartcard mode='host-certificates' => backend=certificates).
Why is libvirt assuming anything about a feature that isn't in upstream QEMU? Regards, Anthony Liguori
Is it possible for qemu to have support for one, but not both, of those modes? If that's the case, then supporting "backend=nss-emulated/certificates" in -device ccid-card-emulated,? would be handy for libvirt (for example, it would be just "backend=certificates" if nss-emulated is not available). But if it's an all-or-none approach (all backends are available if ccid-card-emulated is present), then libvirt's current code won't be impacted by changing the string to the simpler "backend=string".
participants (3)
-
Alon Levy -
Anthony Liguori -
Eric Blake