From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: qemu-devel <qemu-devel@nongnu.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: About improving devices and renaming migration stream...
Date: Thu, 4 Jun 2020 09:33:01 +0200 [thread overview]
Message-ID: <b24c8f81-703c-16c2-94e9-e485962eca42@redhat.com> (raw)
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.
next reply other threads:[~2020-06-04 7:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 7:33 Philippe Mathieu-Daudé [this message]
2020-06-04 9:27 ` About improving devices and renaming migration stream Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b24c8f81-703c-16c2-94e9-e485962eca42@redhat.com \
--to=philmd@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).