From: Kevin Wolf <kwolf@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
"open list:Network Block Dev..." <qemu-block@nongnu.org>,
BALATON Zoltan <balaton@eik.bme.hu>,
"Daniel P. Berrange" <berrange@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: -drive if=none: can't we make this the default?
Date: Tue, 31 Oct 2023 19:44:12 +0100 [thread overview]
Message-ID: <ZUFK/BHG2WMhAiWG@redhat.com> (raw)
In-Reply-To: <e3bb64a2-fb72-4e8d-a0b2-89ee35365fb3@tls.msk.ru>
Hi Michael,
I didn't see this thread when you posted it, sorry for being a bit late.
Am 16.10.2023 um 13:58 hat Michael Tokarev geschrieben:
> Almost everyone mentions -blockdev as a replacement for -drive.
More specifically for -drive if=none. I honestly don't know many common
use cases for that one.
For management tools, -blockdev is indeed what should be used, and that
things are more explicit there is actually a feature, not a bug, for
management tools.
As a human user, in the common case where I don't care about the
details, I don't want to type up an explicit -device. if=virtio gives me
more directly what I want.
So you only need it when you want to specify one of the more exotic
-device options, which shouldn't happen that often. Well, it doesn't for
me anyway, other people may have other use cases. Is that your case? If
so, which options do you usually want to give to -device?
> But I have to remind several issues with it:
>
> 1. While documentation has improved a lot, -blockdev is still mostly unknown
> to the masses.
And for manual human use, that's okay anyway - you probably don't want
to use it. But if you're writing scripts or even advanced management
software, then you should use it.
(Of course, in complex cases you may have to use it manually anyway
because -drive has some limitations, but that should be the absolute
exception.)
> 2. -blockdev is just too verbose, one have to specify a lot of parameters just to
> do a simple thing which is solved with an extra parameter with -drive.
> Including various backing stores/chains for qcow2 files - this is terrible for
> using things manually from command line
You don't have to specify the backing chain explicitly if you're happy
with the default options with which the backing files are opened.
-blockdev options are typically a bit longer than -drive ones, but not
extremely. The separate -device that if=none gives you is already a
similar amount of extra typing.
-drive if=virtio,file=test.qcow2
-drive if=none,file=test.qcow2,id=disk -device virtio-blk,drive=disk
-blockdev qcow2,file.driver=file,file.filename=test.qcow2,node-name=disk -device virtio-blk,drive=disk
> 3. -blockdev does not work with -snapshot
>
> 4. Something else I forgot while typing all the above :)
>
> In my view, -blockdev is not a substitute for -drive, not at all, and it is
> very user-unfriendly. This is why -drive seems to be a good trade-off between
> things like -hda (which is just too simplistic) and -blockdev which which is
> way too verbose and lacks some automatic sugar like -snapshot.
I would agree with that, but if=none already feels a bit unfriendly.
Honestly, I would like to throw away the existing -drive and replace it
with one that has a simpler implementation (as a wrapper around
-blockdev) and I would be happy if it gained some additional options for
passing through things to -device so that you don't have to bother with
if=none even in the more complex cases any more.
It would be pure syntactic sugar with a similar compatibility promise as
in HMP (we won't break it just for fun, but we'll also not stop making
sensible changes just because they make things look a bit different).
Kevin
next prev parent reply other threads:[~2023-10-31 18:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-14 19:16 -drive if=none: can't we make this the default? Michael Tokarev
2023-10-14 19:59 ` BALATON Zoltan
2023-10-31 18:56 ` Kevin Wolf
2023-10-16 8:57 ` Daniel P. Berrangé
2023-10-16 9:55 ` Paolo Bonzini
2023-10-16 11:58 ` Michael Tokarev
2023-10-31 18:44 ` Kevin Wolf [this message]
2023-11-01 11:21 ` Peter Maydell
2023-11-02 7:09 ` Markus Armbruster
2023-11-02 10:43 ` Kevin Wolf
2023-11-02 11:01 ` Peter Maydell
2023-11-02 14:06 ` Kevin Wolf
2023-11-02 14:11 ` Michael Tokarev
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=ZUFK/BHG2WMhAiWG@redhat.com \
--to=kwolf@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=berrange@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.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 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).