On Wed, Dec 03, 2014 at 01:35:18PM +0100, Gerd Hoffmann wrote: > Hi, > > > Hmm, so it occurrs to me that this is really about detecting what > > BIOS capabilities QEMU is able to support. > > IMHO this isn't a property of qemu, but a property of the firmware. > > Thats why I think the firmware packages should include some config file > with the meta data. It feels related to QEMU because you need to have info about whether to use -bios or -pflash, and info about the format raw vs qcow2 and whether the firmware is compatible with the particular system emulator arch. > > We have standardized on > > interogating QEMU via QMP for this purpose. So rather than libvirt > > having to know about paths, or config files, I wonder if QEMU should > > own this knowledge and then expose the information via QMP. > > We could have qemu parse the firmware config files and export this via > qmp, but I fail to see the benefits this extra indirection brings us. The location of the firmware and/or firmware config files can vary depending on what $PREFIX QEMU was installed in. I don't think that external apps should have to care about where the firmware or the firmware config files are installed - that's QEMU's build time knowledge. All an mgmt app should need to care about is the path to the QEMU binary and from that it should be able to interrogate QEMU to find out everything else and not have to hardcode any info like paths to extra assets related to QEMU. Regards, 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list