qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.



             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).