From: Markus Armbruster <armbru@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
libvir-list@redhat.com, QEMU <qemu-devel@nongnu.org>,
"Marc-André Lureau" <marcandre.lureau@gmail.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [PATCH 2/2] Add -mem-shared option
Date: Tue, 10 Dec 2019 11:34:32 +0100 [thread overview]
Message-ID: <87tv6831vr.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20191209205840.GJ498046@habkost.net> (Eduardo Habkost's message of "Mon, 9 Dec 2019 17:58:40 -0300")
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.
next prev parent reply other threads:[~2019-12-10 10:35 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-28 14:15 [PATCH 0/2] RFC: add -mem-shared option Marc-André Lureau
2019-11-28 14:15 ` [PATCH 1/2] memfd: add qemu_memfd_open() Marc-André Lureau
2019-11-28 14:15 ` [PATCH 2/2] Add -mem-shared option Marc-André Lureau
2019-11-28 16:14 ` Eduardo Habkost
2019-11-28 16:28 ` Igor Mammedov
2019-11-28 20:31 ` Marc-André Lureau
2019-11-29 10:07 ` Igor Mammedov
2019-11-29 10:11 ` Paolo Bonzini
2019-11-29 12:01 ` Markus Armbruster
2019-11-29 20:31 ` Eduardo Habkost
2019-11-29 12:16 ` Igor Mammedov
2019-11-29 17:46 ` Paolo Bonzini
2019-12-02 7:39 ` Igor Mammedov
2019-12-02 21:00 ` Eduardo Habkost
2019-12-03 8:56 ` Thomas Huth
2019-12-03 14:43 ` Igor Mammedov
2019-12-09 20:58 ` Eduardo Habkost
2019-12-10 10:34 ` Markus Armbruster [this message]
2019-12-10 13:09 ` Igor Mammedov
2019-12-03 21:34 ` Eduardo Habkost
2019-11-28 16:10 ` [PATCH 0/2] RFC: add " Eduardo Habkost
2019-11-29 9:18 ` Igor Mammedov
2019-11-29 9:31 ` Paolo Bonzini
2019-11-29 10:23 ` Igor Mammedov
2019-11-29 11:21 ` Paolo Bonzini
2019-11-29 20:21 ` Eduardo Habkost
2019-12-01 15:40 ` Marc-André Lureau
2019-12-01 18:03 ` Paolo Bonzini
2019-11-28 16:59 ` Dr. David Alan Gilbert
2019-11-29 9:23 ` Igor Mammedov
2019-12-13 11:39 ` Stefan Hajnoczi
2019-12-13 13:12 ` Igor Mammedov
2019-11-29 4:37 ` no-reply
2019-11-29 5:34 ` no-reply
2019-11-29 7:02 ` Gerd Hoffmann
2019-11-29 7:30 ` Marc-André Lureau
2019-11-29 9:27 ` Daniel P. Berrangé
2019-11-29 9:31 ` Marc-André Lureau
2019-11-29 9:42 ` Daniel P. Berrangé
2019-11-29 9:45 ` Marc-André Lureau
2019-11-29 11:44 ` Gerd Hoffmann
2019-11-29 9:33 ` Paolo Bonzini
2019-11-29 9:39 ` Daniel P. Berrangé
2019-11-29 9:52 ` Paolo Bonzini
2019-11-29 10:13 ` Igor Mammedov
2019-11-29 11:20 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tv6831vr.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=libvir-list@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.