On Tue, 10 Dec 2019 11:34:32 +0100 Markus Armbruster <armbru@xxxxxxxxxx> wrote: > Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: > > > +Markus > > > > On Tue, Dec 03, 2019 at 03:43:03PM +0100, Igor Mammedov wrote: > >> 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 > > > > Global properties are a convenient way to expose knobs through > > the command line with little effort, but we have no documentation > > on which QOM properties are really supposed to be touched by > > users using -global. > > > > Unless we fix the lack of documentation, I'd prefer to have > > syntactic sugar translated to -global instead of recommending > > direct usage of -global. > > Fair point. > > I'd take QOM property documentation over still more sugar. > > Sometimes, the practical way to make simple things simple is sugar. I > can accept that. This doesn't look like such a case, though. I can document concrete globals as replacement at the place -mem-path/-mem-prealloc are documented during deprecation and then in 2 releases we will just drop legacy syntax and keep only globals over there. (eventually it will spread various globals over man page, which I don't like but we probably should start somwhere and consolidate later if globals in man page become normal practice.) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
