On 07/08/2011 10:14 AM, Richard W.M. Jones wrote:
On Fri, Jul 08, 2011 at 09:19:46AM -0500, Adam Litke wrote:
Hi all,
In order to nicely support domains that use qemu's SDL support, libvirt-cim is looking for a way to confirm if the underlying qemu emulator can support SDL. Libvirt already knows this information internally. It seems to me that the best way to provide this information is by reporting it as a guest feature via the capabilities API call. I was thinking the node '/capabilities/guest/features/sdl' could be added when qemu supports SDL.
Is this a good idea?
Seems like clearly a good idea to me. (Although I don't have to code it :-)
Don't worry :) I think we have a motivated party.
Would it be worth having a separate <graphics> element underneath features, so the path would be /capabilities/guest/features/graphics/sdl ?
I only think this would be needed if we are going to add other graphics-related features. Can you think of other features that would fit? I think libvirt always assumes some form of vnc support so there may not be a need to enumerate graphics types. We might want to advertise spice support, but that wouldn't fit strictly under graphics because spice affects much more than the graphics device. Is there a desire to eventually add support for enumerating the different models of devices that qemu can emulate? For example, [ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet, virtio] for network models? If so, we may want to place this information in a more structured hierarchy /capabilities/guest/devices/net/models/. Either way, SDL support isn't part of the device model so it would probably make sense to place it directly under 'features' IMO. -- Adam Litke IBM Linux Technology Center