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 With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
