Re: [libvirt] [PATCH 2/2] Add -mem-shared option
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@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. Thomas [1] Using the terms from: https://www.youtube.com/watch?v=Oscjpkns7tM&t=8m
On Tue, 3 Dec 2019 09:56:15 +0100 Thomas Huth <thuth@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@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
Thomas
[1] Using the terms from: https://www.youtube.com/watch?v=Oscjpkns7tM&t=8m
+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@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@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. -- Eduardo
Eduardo Habkost <ehabkost@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@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@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.
Eduardo Habkost <ehabkost@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@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@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. I can document concrete globals as replacement at the place -mem-path/-mem-prealloc are documented during deprecation and
On Tue, 10 Dec 2019 11:34:32 +0100 Markus Armbruster <armbru@redhat.com> wrote: 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.)
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@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
participants (4)
-
Eduardo Habkost -
Igor Mammedov -
Markus Armbruster -
Thomas Huth