All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, John Snow <jsnow@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: proposal: deprecate -readconfig/-writeconfig
Date: Fri, 15 May 2020 07:31:12 +0200	[thread overview]
Message-ID: <87k11dsr1b.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20200514085418.hmglfmz5rn7lsqe4@sirius.home.kraxel.org> (Gerd Hoffmann's message of "Thu, 14 May 2020 10:54:18 +0200")

Gerd Hoffmann <kraxel@redhat.com> writes:

> On Thu, May 14, 2020 at 10:09:21AM +0200, Paolo Bonzini wrote:
>> IMHO configuration files are in general a failed experiment.  In
>> practice, they do not add much value over just a shell script because
>> they don't allow configuring all QEMU options, they are very much fixed
>> (by their nature).  I think it's more or less agreed that they are not
>> solving any problem for higher-level management stacks as well; those
>> would prefer to configure the VM via QMP or another API.
>> 
>> So, any objections to deprecating -readconfig and -writeconfig?
>
> -writeconfig surely can go away, it never reached the point where it
> could write out an configuration which is actually complete.
>
> -readconfig is a bit more tricky, it's actually useful.  I'm using it
> sometimes.

I use it all the time.

>             Also we have docs/config/ with a bunch of files you can
> pass to -readconfig.

True.

> I can see that it'll stand in the way if we want move away from QemuOpts
> to something else (say qom-based yaml/json config files), so I wouldn't
> veto deprecation, but I'd prefer it not being actually dropped until the
> replacement is ready and the stuff in docs/config/ being converted to
> the new scheme.

I want QemuOpts replaced, and I want its replacement to support
configuration files.

The replacement effort needs some license for incompatible change.  The
less license, the harder the job becomes.

The configuration file format is among the things that'll change.

QemuOpts was a reasonable step forward back when you invented it, and it
served us well for some time, but we've outgrown it.  It's basically
two-level: configuration group ("drive", "chardev", "device", ...) and
option parameter (for "chardev": "backend", "path", "host", ...).  We
really need trees now.  I can't see how to grow the current INI-like
configuration file syntax compatibly to trees without making it overly
verbose.

Telling users now not to rely on the configuration file format to remain
compatible makes sense to me.



  reply	other threads:[~2020-05-15  5:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  8:09 proposal: deprecate -readconfig/-writeconfig Paolo Bonzini
2020-05-14  8:54 ` Gerd Hoffmann
2020-05-15  5:31   ` Markus Armbruster [this message]
2020-05-14  8:56 ` Daniel P. Berrangé
2020-05-14 12:37   ` Paolo Bonzini
2020-05-15  5:54     ` Markus Armbruster
2020-05-15 10:19       ` Paolo Bonzini
2020-05-14 14:40   ` John Snow
2020-05-14 15:34     ` Daniel P. Berrangé
2020-05-14 15:51       ` Paolo Bonzini
2020-05-14 15:55         ` Daniel P. Berrangé
2020-05-15  5:44           ` Markus Armbruster
2020-05-15  5:51       ` Markus Armbruster
2020-05-15  9:06     ` Gerd Hoffmann

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=87k11dsr1b.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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.