qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Reinoud Zandijk" <reinoud@netbsd.org>,
	"Ryo ONODERA" <ryoon@netbsd.org>,
	qemu-block@nongnu.org, "Hanna Reitz" <hreitz@redhat.com>,
	"Warner Losh" <imp@bsdimp.com>, "Beraldo Leal" <bleal@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Kyle Evans" <kevans@freebsd.org>,
	kvm@vger.kernel.org,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Michael Tokarev" <mjt@tls.msk.ru>,
	armbru@redhat.com
Subject: Re: [PATCH v2 05/11] qemu-options: finesse the recommendations around -blockdev
Date: Tue, 4 Apr 2023 15:57:17 +0200	[thread overview]
Message-ID: <ZCwsvaxRzx4bzbXo@redhat.com> (raw)
In-Reply-To: <20230403134920.2132362-6-alex.bennee@linaro.org>

Am 03.04.2023 um 15:49 hat Alex Bennée geschrieben:
> We are a bit premature in recommending -blockdev/-device as the best
> way to configure block devices, especially in the common case.
> Improve the language to hopefully make things clearer.
> 
> Suggested-by: Michael Tokarev <mjt@tls.msk.ru>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Message-Id: <20230330101141.30199-5-alex.bennee@linaro.org>
> ---
>  qemu-options.hx | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 59bdf67a2c..9a69ed838e 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1143,10 +1143,14 @@ have gone through several iterations as the feature set and complexity
>  of the block layer have grown. Many online guides to QEMU often
>  reference older and deprecated options, which can lead to confusion.
>  
> -The recommended modern way to describe disks is to use a combination of
> +The most explicit way to describe disks is to use a combination of
>  ``-device`` to specify the hardware device and ``-blockdev`` to
>  describe the backend. The device defines what the guest sees and the
> -backend describes how QEMU handles the data.
> +backend describes how QEMU handles the data. The ``-drive`` option
> +combines the device and backend into a single command line options
> +which is useful in the majority of cases. Older options like ``-hda``
> +bake in a lot of assumptions from the days when QEMU was emulating a
> +legacy PC, they are not recommended for modern configurations.

Let's not make the use of -drive look more advisable than it really is.
If you're writing a management tool/script and you're still using -drive
today, you're doing it wrong.

Maybe this is actually the point where we should just clearly define
that -blockdev is the only supported stable API (like QMP), and that
-drive etc. are convenient shortcuts for human users with no
compatibility promise (like HMP).

What stopped us from doing so is that there are certain boards that
don't allow the user to configure the onboard devices, but that look at
-drive. These wouldn't provide any stable API any more after this
change. However, if this hasn't been solved in many years, maybe it's
time to view it as the board's problem, and use this change to motivate
them to implement ways to configure the devices. Or maybe some don't
even want to bother with a stable API, who knows.

Kevin



  reply	other threads:[~2023-04-04 13:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-03 13:49 [PATCH v2 00/11] more misc fixes for 8.0 (tests, gdbstub, meta, docs) Alex Bennée
2023-04-03 13:49 ` [PATCH v2 01/11] scripts/coverage: initial coverage comparison script Alex Bennée
2023-04-03 13:49 ` [PATCH v2 02/11] gdbstub: Only build libgdb_user.fa / libgdb_softmmu.fa if necessary Alex Bennée
2023-04-03 13:49 ` [PATCH v2 03/11] gdbstub: don't report auxv feature unless on Linux Alex Bennée
2023-04-03 13:49 ` [PATCH v2 04/11] MAINTAINERS: add a section for policy documents Alex Bennée
2023-04-03 13:49 ` [PATCH v2 05/11] qemu-options: finesse the recommendations around -blockdev Alex Bennée
2023-04-04 13:57   ` Kevin Wolf [this message]
2023-04-04 14:55     ` Alex Bennée
2023-04-04 15:07     ` Michael Tokarev
2023-04-04 16:17       ` Kevin Wolf
2023-04-06 20:23         ` Reinoud Zandijk
2023-04-11 12:09           ` Kevin Wolf
2023-04-11 13:03             ` Alex Bennée
2023-04-03 13:49 ` [PATCH v2 06/11] metadata: add .git-blame-ignore-revs Alex Bennée
2023-04-03 13:49 ` [PATCH v2 07/11] Use hexagon toolchain version 16.0.0 Alex Bennée
2023-04-03 13:49 ` [PATCH v2 08/11] tests/qemu-iotests: explicitly invoke 'check' via 'python' Alex Bennée
2023-04-03 13:49 ` [PATCH v2 09/11] tests/vm: use the default system python for NetBSD Alex Bennée
2023-04-04 11:24   ` Philippe Mathieu-Daudé
2023-04-03 13:49 ` [PATCH v2 10/11] gitlab: fix typo Alex Bennée
2023-04-03 13:49 ` [PATCH v2 11/11] tests/avocado: Test Xen guest support under KVM Alex Bennée

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=ZCwsvaxRzx4bzbXo@redhat.com \
    --to=kwolf@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=bleal@redhat.com \
    --cc=crosa@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=imp@bsdimp.com \
    --cc=kevans@freebsd.org \
    --cc=kvm@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=reinoud@netbsd.org \
    --cc=ryoon@netbsd.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@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).