Re: [libvirt] adding smartcard support to libvirt

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.