[libvirt] adding smartcard support to libvirt

[Eric Blake]

On 01/06/2011 04:33 AM, Alon Levy wrote:
>> Hmm, right now, the only use of spice in XML is under <graphics
>> type='spice'>, and it is the <graphics> element that contains port,
>> tlsPort, autoport, and listen arguments.  So we may need to revisit
>> that, and have some way to use a single location for spice parameters
>> shared among all spice-related devices, and a way for both <graphics
>> type='spice'> and <smartcard type='passthrough'> to reference that
>> rather than repeating it.  Meaning that spicevmc support just got more
>> difficult, if it involves tweaking <graphics> rather than just adding a
>> new <channel type='spicevmc'> element.
> 
> Are you saying that for correctness you want to tie the two elements together?
> I mean, that's the only possible reason I see. If you want to tie them
> together to prevent an instance of spicevmc without an instance of graphics
> of type spice, I understand. I guess (after seeing the patch you sent) there
> is a verifier to the xml inputs to libvirt that would be able to deduce invalidity
> in that case?
> Of course the alternative is to have logic elsewhere, but I see the point in
> trying to verify the xml input only at one place.

I'm thinking more along the lines that the spice parameters (port,
tlsport, autoPort, listen, passwd, and child <channel> elements main,
display, inputs, cursor, playback, and record) _might_ need to be
specified independently from their current position under <graphics>,
since we are likely adding new channels.  That is, I think it should be
possible to use a spicevmc agent for _just_ a smartcard channel, while
still using older vnc or other graphics, in which case specifying spice
parameters living under <graphics> doesn't make sense, but neither
should the spice parameters live under <smartcard>.  For that reason, it
does seem to argue that creating a top-level <spice> element would make
sense.

However, it's a tricky proposition, because we have to maintain
backwards compatibility; so _if_ we decide that making a higher-level
<spice> element for fine-tuning spice parameters (rather than the
current approach of sticking spice parameters under <graphics>), then
yes, the XML parser will have to do consistency checks that either spice
parameters are only provided in one location, or that the multiple
locations are consistent.

At any rate, I'm not going to give spicevmc much further thought until I
first get <smartcard> with tcp passthru working, so it may be a few more
days before I reply any further on this portion of the thread.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110106/d85d83c0/attachment-0001.sig>