On 07/02/2014 06:28 PM, Nicholas A. Bellinger wrote:
> QEMU is not the only hypervisor that libvirt targets, so tieing
libvirt
> names to QEMU names is a non-goal. We pick the names that make most sense
> in the context of libvirt.
>
Not sure I follow.. virtio-scsi is specific to QEMU/KVM, and per the
comment in the original patch:
'Currently it only supports attribute <code>queues</code> (<span
class="since">1.0.5</span>, QEMU and KVM only)'
would seem to indicate the parameter names are only used in the context
of QEMU/KVM, no..?
Just because qemu is the only hypervisor driver that _currently_ uses
the feature doesn't preclude the libxl hypervisor from _also_ gaining
support for the feature in a future libvirt release, at which point the
documentation would mention the new version number for the additional
use of the feature. Again, the name qemu chose is not necessarily the
best name compared to what it might map to in libxl or any other
hypervisor, so libvirt tries to pick names that are consistent with
other libvirt terms, even if they don't match underlying qemu names.
If the virtio-scsi parameters are intended to be used across
hypervisors, then matching them to QEMU's own names doesn't really
matter. But if they are specific to virtio-scsi and only used by
QEMU/KVM instances, then renaming them to something arbitrary to libvirt
is pointless and confusing.
virtio is not necessarily a qemu-only concept.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org