Re: Summary of Re: Making QEMU easier for management tools and applications

[Peter Maydell]

On Mon, 10 Feb 2020 at 11:08, Daniel P. Berrangé <address@hidden> wrote:
>
> On Mon, Feb 10, 2020 at 11:01:48AM +0000, Peter Maydell wrote:
> > On Mon, 10 Feb 2020 at 10:57, Stefan Hajnoczi <address@hidden> wrote:
> > > I'm in favor of simplifying QEMU at the expense of an incompatible CLI
> > > change in QEMU 6.0.
> >
> > If we want to do wholesale incompatible changes to the CLI
> > I think we definitely need some kind of tool where a user
> > can say "here's my old command line, what's the new style
> > equivalent?". Otherwise we're going to have a deluge of
> > user issues where their old working setups broke and
> > QEMU didn't give them any useful hints about why.
>
> There is a risk that if we promise to have a fully automated conversion
> that it will be alot of work, and could force us to introduce hacks into
> the new impl just to satisfy conversion.  IMHO we shouldn't be afraid of
> declaring that some parts of the old syntax can NOT be directly transformed
> into new syntax, simply for the sake of making a new impl more practical
> to move forward with.

Agreed, but we should at least be able to handle the easy
stuff and say "this is the general kind of new option syntax
and set of options you want" for most of the rest.

> An alternative approach to mitigate the disruption is to *not* make any
> incompatible changes to qemu-system-XXXX. Instead introduce new binaries
> with the new syntax and any other architectural  changes we wish to make.
> The old binaries can be deprecated but remain around for an extended
> period of time, to give people and apps time to migrate. We can provide
> rough guidance and perhaps partially automated conversion to help people
> move, but not aim for a 100% automated conversion.

I think our history of failing to actually complete transitions
would predict that we'd end up with both the old and the new
binaries essentially forever.

thanks
-- PMM