On Tue, Mar 15, 2011 at 02:40:04PM +0100, Jes Sorensen wrote: > On 03/15/11 14:14, Alon Levy wrote: > > On Tue, Mar 15, 2011 at 01:42:56PM +0100, Jes Sorensen wrote: > >> Alternatively the external apps that build against it should be taught > >> to link with the QEMU version. > >> > > > > That would require me to teach qemu's configure to build libcacard, possibly > > only libcacard (even though qemu doesn't need a lot of packages by itself, > > I still wouldn't want apt-get install spice-client to drag in qemu-kvm). > > Hi Alon, > > I am a little confused as to what the library really does. Is it a > library to manage iso7816 cards, or is it an emulation library? If it is emulation library.
> hw emulation the library really should be part of qemu.git, but there is > nothing that prevents us to expanding the qemu Makefile to build the > library and then have a separate RPM called qemu-libs or something that > can be installed without the main qemu RPM being installed. Yes, that's what I was thinking about. Of course we can do it downstream (in fedora/rhel), but I'd rather have an upstream make target / configure option == solution.. > > Can you elaborate a bit on how spice uses libcacard? I can understand it > relying on a library to access/manage smartcards, but the emulation bit > puzzles me? > If no emulation was required in the middle we would have just done usb forwarding. The fact is we need the client and the guest to access the card at the same time, potentially the client and a few guests. Because there is no locking in the smartcard protocol, no idea of multiple outstanding requests, this requires giving each guest it's own card state, that is emulating a card. libcacard emulates a CAC, that is a Common Access Card. So the second option. The reader emulation is naturally part of the pc emulation, so qemu is the right place. There are two locations to do the card emulation, currently both are implemented: * in the pc emulator: ccid-card-emualted. This links with the libcacard files (well, the way we do linking it links with all the world, but it uses that code, those symbols). * in the client: that's what spice uses. in the vm side we have ccid-card-passthru, over the wire we get the APDU's (application protocol data unit for the 7186 standard, which the CAC standard uses), and the card emulation itself is done in the client, via linking with libcacard (the standalone one). Obviously it would have been simpler if we decided from the start to do what anthony wanted, that is to emulate in the host/pc. But we/I didn't, it seemed easier to emulate in the client, and also I thought more performant. The performance part really depends on which latency is more important, and no benchmarks have been done. So right now contents wise (I mean, what's in this patchset) I think we are over the question of which devices will be accepted in qemu, we are just down to the question of what color the code should be, and I'll be sending v21 once I fix the review concerns. > If libcacard does both card management and emulation, my next question > is whether it wouldn't make more sense to split the two into two > separate packages? > > Cheers, > Jes >
