Hello Dave, ==[background]==
I've been doing this pflash rework: * Add abstract TYPE_NOR_FLASH - qdev type - blockdev backend - manage bank/sector, - manage timer for erase/write delays - can be used by I2C/SPI NOR flash too * Add abstract TYPE_PARALLEL_NOR_FLASH - mostly SysBusDevice bindings * Add TYPE_COMMON_FLASH_MEMORY_INTERFACE - common CFI code - abstracts CFI methods * Refactor TYPE_PFLASH_CFI02 -> TYPE_PARALLEL_NOR_CFI02_FLASH - Inherit TYPE_NOR_FLASH -> TYPE_PARALLEL_NOR_FLASH - Implements TYPE_COMMON_FLASH_MEMORY_INTERFACE I kept the harder for the end... (maybe bad idea): - migration - CFI01 ==[problems]== 1/ Can I change the name of a migration stream? I want to add migration from old TYPE_PFLASH_CFI02 to TYPE_PARALLEL_NOR_CFI02_FLASH, and deprecate TYPE_PFLASH_CFI02. >From docs/devel/migration.rst: "The ``ID string`` is normally unique, having been formed from a bus name and device address, PCI devices and storage devices hung off PCI controllers fit this pattern well. Some devices are fixed single instances (e.g. "pc-ram"). Others (especially either older devices or system devices which for some reason don't have a bus concept) make use of the ``instance id`` for otherwise identically named devices." I started TYPE_PARALLEL_NOR_CFI02_FLASH from a clean design, I'm not sure I can redo everything keeping the same type name. Is it possible to use massaging functions to migrate from TYPE_A (version y) to TYPE_B (version x)? 2/ Do I need to care about backward compatibility? I understand we want to migrate from old -> new QEMU version. >From docs/devel/migration.rst: "In general QEMU tries to maintain forward migration compatibility (i.e. migrating from QEMU n->n+1) and there are users who benefit from backward compatibility as well." When is it important to migrate from new -> old? Can this be a blocker? Am I doomed to keep the old device forever? Is this what are versioned machines for? I.e. adding machine-v6 that start with the newer devices, breaking backward compat. Thanks, Phil.
