Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Aug 04, 2022 at 04:56:15PM +0200, Markus Armbruster wrote: >> Daniel P. Berrangé <berra...@redhat.com> writes: >> >> > On Thu, Jul 28, 2022 at 10:46:35AM +0100, Peter Maydell wrote: >> >> On Wed, 27 Jul 2022 at 20:03, Kevin Wolf <kw...@redhat.com> wrote: >> >> > >> >> > Am 18.07.2022 um 11:49 hat Markus Armbruster geschrieben: >> >> > > An OTP device isn't really a parallel flash, and neither are eFuses. >> >> > > More fast-and-lose use of IF_PFLASH may exist in the tree, and maybe >> >> > > of >> >> > > other interface types, too. >> >> > > >> >> > > This patch introduces IF_OTHER. The patch after next uses it for an >> >> > > EEPROM device. >> >> > > >> >> > > Do we want IF_OTHER? >> >> > >> >> > What would the semantics even be? Any block device that doesn't pick up >> >> > a different category may pick up IF_OTHER backends? >> >> > >> >> > It certainly feels like a strange interface to ask for "other" disk and >> >> > then getting as surprise what this other thing might be. It's >> >> > essentially the same as having an explicit '-device other', and I >> >> > suppose most people would find that strange. >> >> > >> >> > > If no, I guess we get to abuse IF_PFLASH some more. >> >> > > >> >> > > If yes, I guess we should use IF_PFLASH only for actual parallel flash >> >> > > memory going forward. Cleaning up existing abuse of IF_PFLASH may not >> >> > > be worth the trouble, though. >> >> > > >> >> > > Thoughts? >> >> > >> >> > If the existing types aren't good enough (I don't have an opinion on >> >> > whether IF_PFLASH is a good match), let's add a new one. But a specific >> >> > new one, not just "other". >> >> >> >> I think the common thread is "this isn't what anybody actually thinks >> >> of as being a 'disk', but we would like to back it with a block device >> >> anyway". That can cover a fair range of possibilities... >> > >> > Given that, do we even want/have to use -drive for this ? We can use >> > -blockdev for the backend and reference that from any -device we want >> > to create, and leave -drive out of the picture entirely >> >> -drive is our only means to configure onboard devices. >> >> We've talked about better means a few times, but no conclusions. I can >> dig up pointers, if you're interested. > > For onboard pflash with x86, we've just got properties against the > machine that we can point to a blockdev.
True, but the vast majority of onboard block devices doesn't come with such properties. Please see Subject: On configuring onboard block devices with -blockdev (was: [PATCH v4 6/7] hw/nvram: Update at24c EEPROM init function in NPCM7xx boards) Date: Mon, 15 Nov 2021 16:28:33 +0100 Message-ID: <875ystigke.fsf...@dusky.pond.sub.org> https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg03173.html
