On 04/04/2014 12:29 AM, Michael R. Hines wrote: > > Yes, it's present, but it still does not guarantee that QEMU supports > it if RDMA was compiled out - only the version number is a > (minimal) guarantee, and even then the hardware can still throw > an error if RDMA itself is not supported. Which sounds like you want a feature test (is it supported in the build you are talking to, answer is always correct) and not a version test (is the build you are talking to new enough to possibly have the feature, but if you guess wrong you may get an error from the hardware) > > I'm still not seeing what's wrong with depending on the version > number since other features are also depending on the version > number. Every feature where we have to guess based on version number is due to a bug in qemu for not providing enough information for libvirt to probe for the feature's existence. We hate those features, and I have been lobbying hard on the qemu list that all NEW features should be discoverable. rdma is one such feature - I recall you making changes in your series there so that it is discoverable in response to my early review comments - so now please USE that methodology from libvirt. > > Are you guys suggesting that we stop depending on version altogether > for *all* QEMU features? Yes, that would be the ideal world. We won't get there any time soon, but feature checks are ALWAYS better than version checks. In fact, that was the philosophy that led to the creation of autoconf. Feature checks are inherently more portable to a wider range of backported forks than any database of version number checks could ever hope to be. -- Eric Blake eblake redhat com +1-919-301-3266 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