On Tue, Mar 19, 2013 at 04:54:46PM +0100, Christophe Fergeau wrote: > On Tue, Mar 19, 2013 at 03:24:22PM +0000, Daniel P. Berrange wrote: > > On Tue, Mar 19, 2013 at 10:46:35AM +0100, Christophe Fergeau wrote: > > > The code was building an id starting with kvm- while libosinfo qemu > > > description uses qemu-kvm-. Also, starting from qemu 1.2.0, there is > > > no separate qemu-kvm tarball. > > > guess_platform_from_connect is starting to be a bit magic, it may > > > be better to add a <machine> attribute to libosinfo <platform> > > > description and to use this to improve the matching between > > > libosinfo data and libvirt caps. > > > > I've never been able to think up a satisfactory way to do the > > mapping yet, without black magic like this. The trick is we don't > > want to tie libosinfo to libvirt concepts directly, since we want > > it to be generally useful to anyone doing virt stuff regardless > > of whether they use libvirt. > > Agreed on not tying too much libosinfo with libvirt concepts. The <machine> > tag seemed acceptable from that perspective as this initially is a qemu > concept, so not too deeply tied to libvirt. > Alternatively, maybe we can ship some specialized datamaps to transform > libosinfo short IDs to something meaningful in a libvirt/... context. > Applications could pick the most appropriate one depending on what they are > using.
Perhaps we should be following the approach we use for detecting ISOs, and match against actual product release strings. Libvirt doesn't expose such info, but we could add an API to expose the full product string and/or version string. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
