On Tue, 3 Dec 2019 09:56:15 +0100 Thomas Huth <thuth@xxxxxxxxxx> 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@xxxxxxxxxx> 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 > overcrowded, we should try to keep it as clean as possible. After switching to memdev for main RAM, users could use relatively short global options -global memory-backend.prealloc|share=on and -global memory-backend-file.mem-path=X|prealloc|share=on instead of us adding and maintaining slightly shorter -mem-shared/-mem-path/-mem-prealloc > Thomas > > > [1] Using the terms from: > https://www.youtube.com/watch?v=Oscjpkns7tM&t=8m -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
