[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
About improving devices and renaming migration stream...
From: |
Philippe Mathieu-Daudé |
Subject: |
About improving devices and renaming migration stream... |
Date: |
Thu, 4 Jun 2020 09:33:01 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
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.
- About improving devices and renaming migration stream...,
Philippe Mathieu-Daudé <=