Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help

[Anthony Liguori]

On 07/26/2010 02:19 PM, Avi Kivity wrote:
> > Is what we are supporting just what libvirt expects there to be or 
> > what any tool out there expects there to be?
>
> We should try to support all users, prioritized by the number of end 
> users they represent.  If this patch broke some other large user we'd 
> be in a bind.  But likely this isn't the case so we aren't.

As I've said, I'm pragmatic and that's why I've argued for these changes 
in the past.  But libvirt should have changed a long time ago to using 
something more reliable (like version).

> > It's not.  Our help output is unreadable.  The (artificial) 
> > restrictions we're putting ourselves with respect to the help output 
> > prevents it from being improved.
>
> Are you saying
>
>
>     "       [,cache=writethrough|writeback|unsafe|none][,format=f]\n"
>
> is more readable than
>
>     "       [,cache=writethrough|writeback|none|unsafe][,format=f]\n"
>
> ?  if so I disagree.

Absolutely.  But I meant in the general sense.

> > Backports are such a special case.  Honestly, we're talking about 
> > RHEL and it's trivially easy for libvirt to just special case RHEL.
>
>
> As it happens the patch came from a Novell employee, so it isn't about 
> RHEL.

SLES doesn't carry many backported features.  The reason this hit Bruce 
is that libvirt is detecting using help because of RHEL.

>   I applaud your choice of enterprise operating systems, however.
>
> Regardless, outside of Windows users qemu will mostly be consumed via 
> distribution branches, with different levels of backport happiness.  
> We should recognize that and work with it, not against it.

And it's trivially easy for libvirt to deal with this.  They simply have 
to do: `cat /etc/redhat-release` or `cat /etc/suse-release` and adjust 
version logic accordingly.

It's an easy change for libvirt to make, and the problem goes away for 
the future.  If such a change was made, I'd be inclined to take a patch 
like this now to make up for the difference.

But as I said, we've been accommodating libvirt's use of help for a long 
time now.  We shouldn't let perfect (omnipotent capabilities system) 
stand in the way of good (version/feature matrix).

> > > I don't see what we gain by not doing this.
> >
> > We're losing the ability to make *any* change to our help system by 
> > encouraging it to be used in this fashion.
>
> If we could point libvirt towards a better way of doing things (not a 
> better regexp, which could just break under different circumstances; a 
> supported interface) I'd agree.  Go RTFM chapter-this-or-that and 
> don't bother me no more.  But we can't.

Again, give me an example of where versioning isn't simple and robust 
that applies to things as they stand today and I'm happy to agree with you.

> > > If you want libvirt to do the right thing, provide a proper 
> > > capabilities interface.  Using the version has its downsides as much 
> > > as the help text.
> >
> > That's simply not the case.  Please, provide an actual example where 
> > version is not reliable and backports aren't trivially easy to detect.
>
>
> t=0 starting point, cache=unsafe is unknown
> t=1 qemu upstream adds cache=unknown
> t=2 libvirt adds support for cache=unsafe, releases
> t=3 evil distro backports cache=unsafe, releases qemu-kvm-1.2.3.4
> t=4 user tries libvirt from t=2 with qemu from t=3, cache=unsafe not 
> detected
>
> version numbers force a libvirt update every time a feature is 
> backported.

That's a bogus scenario because said evil distro would also enhance 
libvirt to detect the feature properly.

Regards,

Anthony Liguori