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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list