qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
Cc: 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>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [PATCH 2/2] Add -mem-shared option
Date: Tue, 3 Dec 2019 09:56:15 +0100	[thread overview]
Message-ID: <1ff4cc6a-0ec8-96ff-1e39-e682429852e4@redhat.com> (raw)
In-Reply-To: <20191202210057.GQ14595@habkost.net>

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



  reply	other threads:[~2019-12-03  9:00 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 [this message]
2019-12-03 14:43                     ` Igor Mammedov
2019-12-09 20:58                       ` Eduardo Habkost
2019-12-10 10:34                         ` Markus Armbruster
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=1ff4cc6a-0ec8-96ff-1e39-e682429852e4@redhat.com \
    --to=thuth@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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).