[libvirt] [Qemu-devel] [PATCH for-4.0 v4 0/2] virtio: Provide version-specific variants of virtio PCI devices

[Daniel P. Berrangé]

On Wed, Mar 06, 2019 at 09:30:32AM +0100, Ján Tomko wrote:
> On Wed, Mar 06, 2019 at 08:41:48AM +0100, Peter Krempa wrote:
> > On Tue, Mar 05, 2019 at 16:56:43 +0100, Andrea Bolognani wrote:
> > > On Tue, 2019-03-05 at 15:38 +0100, Gerd Hoffmann wrote:
> > 
> > [...]
> > 
> > > So I agree neither scenario is exactly perfect, but I still think
> > > adding non-transitional alias devices would overall be more
> > > user-friendly.
> > 
> > I don't think it makes sense to add it at the qemu level. From libvirt's
> > point of view users should be shielded from any qemu impl detail or
> > inconsistency as libvirt is the 'user friendly'[1] layer. In qemu the
> > devices would be the same and thus does not make sense to do that
> > because it would be more confusing.
> > 
> > You can argue that we should add the alias at the libvirt level though.
> > 
> 
> You can, but please don't.

Indeed, at the libvirt level we've always tried to take the view that
there should be one way to expressing each concept/feature. Adding
new names / xml elements that duplicate existing supported concepts
to make things "consistent" is a slippery slope becasue there are
100's of places to which that can apply when you have hindsight.

It is not going to make a significant difference to how "user friendly"
libvirt is - that is not a core goal in its own right at the API / XML
schema level. It is can be a factor in deciding between multiple competing
designs when first adding a feature, but it isn't a reason to add duplication
in the API / XML.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|