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/[email protected]/[email protected]/ > 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/[email protected]/ 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?
