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

Markus Armbruster armbru at redhat.com
Tue Dec 10 10:34:32 UTC 2019


Eduardo Habkost <ehabkost at redhat.com> 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 at redhat.com> 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 
>> > 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.




More information about the libvir-list mailing list