From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Cc: Hao Wu <wuhaotsh@google.com>, Bin Meng <bin.meng@windriver.com>,
Alistair Francis <alistair.francis@wdc.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>
Subject: Re: does drive_get_next(IF_NONE) make sense?
Date: Tue, 2 Nov 2021 16:28:53 +0100 [thread overview]
Message-ID: <b8a77903-0120-526f-c58a-b6ab939d033f@redhat.com> (raw)
In-Reply-To: <CAFEAcA9zmPds0+jHm8VY465XEhK6bbVPd+nDob1ruRPaHOua_Q@mail.gmail.com>
On 11/2/21 16:14, Peter Maydell wrote:
> Does it make sense for a device/board to do drive_get_next(IF_NONE) ?
>
> At the moment we have exactly one user of this, which is
> hw/misc/sifive_u_otp.c. This is a model of a one-time-programmable
> fuse, and the drive is providing the backing store for the fuse
> contents. Borrowing an IF_NONE for this seems a bit odd, but
> it's not clear any of the other IF_ types is better.
>
> We also just (this release cycle) added models of the Xilinx
> efuse OTP fuses. Those have been implemented to use IF_PFLASH.
> (This is a somewhat unfortunate inconsistency I guess.)
>
> We also have a patchseries currently in the code review stage
> which uses IF_NONE:
> https://patchew.org/QEMU/20211101232346.1070813-1-wuhaotsh@google.com/20211101232346.1070813-6-wuhaotsh@google.com/
> Here we are trying to provide a drive as backing store for some
> EEPROMs that hang off the i2c buses on some npcm7xx boards.
>
> Are these uses of IF_NONE OK, or should we be doing something
> else (using IF_PFLASH, defining a new IF_*, ???)
IIUC '-drive if=xxx' is deprecated, replaced by '-blockdev'.
Personally I expect a BlockInterfaceType to be a bus interface
and see IF_NONE as a buggy case.
See also:
https://lore.kernel.org/qemu-devel/YDY7KKI1Xme29UlQ@stefanha-x1.localdomain/
I am not sure about the amount of work required to fully leverage
-blockdev and remove -drive. Can it be sugar-expanded from the CLI?
What else is missing to finish the blockdev conversion?
next prev parent reply other threads:[~2021-11-02 15:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-02 15:14 does drive_get_next(IF_NONE) make sense? Peter Maydell
2021-11-02 15:28 ` Philippe Mathieu-Daudé [this message]
2021-11-03 8:41 ` Markus Armbruster
2021-11-03 9:19 ` Thomas Huth
2021-11-12 13:33 ` Markus Armbruster
2021-11-14 17:16 ` Peter Maydell
2021-11-15 5:31 ` Markus Armbruster
2021-11-15 7:12 ` Alistair Francis
2021-11-15 16:09 ` Thomas Huth
2021-11-18 13:03 ` Alistair Francis
2021-11-18 13:20 ` Peter Maydell
2021-11-15 13:24 ` Kevin Wolf
2021-11-15 13:31 ` Peter Maydell
2021-11-15 15:13 ` Kevin Wolf
2021-11-15 15:28 ` Markus Armbruster
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=b8a77903-0120-526f-c58a-b6ab939d033f@redhat.com \
--to=philmd@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=armbru@redhat.com \
--cc=bin.meng@windriver.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wuhaotsh@google.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.