[libvirt] [PATCH 2/2] Add -mem-shared option

[Eduardo Habkost]

On Tue, Dec 03, 2019 at 09:56:15AM +0100, Thomas Huth wrote:
> On 02/12/2019 22.00, Eduardo Habkost wrote:
> > On Mon, Dec 02, 2019 at 08:39:48AM +0100, Igor Mammedov wrote:
> >> On Fri, 29 Nov 2019 18:46:12 +0100
> >> Paolo Bonzini <pbonzini at redhat.com> wrote:
> >>
> >>> On 29/11/19 13:16, Igor Mammedov wrote:
> >>>> As for "-m", I'd make it just an alias that translates
> >>>>  -m/mem-path/mem-prealloc  
> >>>
> >>> I think we should just deprecate -mem-path/-mem-prealloc in 5.0.  CCing
> >>> Thomas as mister deprecation. :)
> >>
> >> I'll add that to my series
> > 
> > Considering that the plan is to eventually reimplement those
> > options as syntactic sugar for memory backend options (hopefully
> > in less than 2 QEMU releases), what's the point of deprecating
> > them?
> 
> Well, it depends on the "classification" [1] of the parameter...
> 
> Let's ask: What's the main purpose of the option?
> 
> Is it easier to use than the "full" option, and thus likely to be used
> by a lot of people who run QEMU directly from the CLI? In that case it
> should stay as "convenience option" and not be deprecated.
> 
> Or is the option merely there to give the upper layers like libvirt or
> some few users and their scripts some more grace period to adapt their
> code, but we all agree that the options are rather ugly and should
> finally go away? Then it's rather a "legacy option" and the deprecation
> process is the right way to go. Our QEMU interface is still way to
> overcrowded, we should try to keep it as clean as possible.

That's a good way to describe the questions involved.  To me they
are clearly convenience options.

We could still replace them with new (more consistent and less
ugly) convenience options, though.

> 
>  Thomas
> 
> 
> [1] Using the terms from:
>     https://www.youtube.com/watch?v=Oscjpkns7tM&t=8m

-- 
Eduardo