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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list