qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/6] vmstate: Add support for alias ID
Date: Thu, 13 May 2010 21:40:43 +0200	[thread overview]
Message-ID: <4BEC55BB.7060503@web.de> (raw)
In-Reply-To: <AANLkTimwkVIsiVNN8fNu89vjg9FABB_nMWJfYsDJOFvS@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

Blue Swirl wrote:
> On 5/13/10, Jan Kiszka <jan.kiszka@web.de> wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>>  Some legacy users (mostly PC devices) of vmstate_register manage
>>  instance IDs on their own, and that unfortunately in a way that is
>>  incompatible with automatically generated ones. This so far prevents
>>  switching those users to vmstates that are registered by qdev.
>>
>>  To establish a migration path, this patch introduces the concept of
>>  alias IDs. They can be passed to an extended vmstate registration
>>  service, and qdev provides a set service to be used during device init.
>>  find_se will consider the alias in addition to the default ID. We can
>>  then start generating the default ID automatically and writing it on
>>  vmsave, thus converting that format without breaking support for upward
>>  migration.
> 
> If this is only for compatibility, I think the name should show it,
> like vmstate_set_compat_instance_id(), or
> vmstate_set_legacy_instance_id(). That way, if there happens to be an
> incompatible version bump, the function name suggests that it can be
> removed.

Hmm, makes some sense, not for the vmstate interface (no new code
outside the core should touch it anymore), but for clarifying the qdev part.

> 
> The function should also take a last_legacy_version_id parameter.
> Consider for example that a vmstate format with the legacy ID is
> currently used with version_id of 2. We also start using this
> compatibility system. A new, compatible version 3 arrives but we only
> want to support legacy ID for version 2, as indicated by
> last_legacy_version_id=2. Then with a new version, let's say 5, which
> is no longer compatible with 2 or 3, the legacy ID stuff can finally
> be thrown away. qdev.c should check if last_legacy_id >=
> minimum_version_id and complain otherwise.

OK, will look into this.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

  reply	other threads:[~2010-05-13 19:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-12 21:19 [Qemu-devel] [PATCH 0/6] vmstate: Drop post_save / allow instance ID aliases Jan Kiszka
2010-05-12 21:19 ` [Qemu-devel] [PATCH 1/6] tmp105: Drop unused faults field Jan Kiszka
2010-05-12 21:19 ` [Qemu-devel] [PATCH 2/6] vmstate: Drop unused post_save handler Jan Kiszka
2010-05-12 21:19 ` [Qemu-devel] [PATCH 3/6] vmstate: Add support for alias ID Jan Kiszka
2010-05-13 19:15   ` Blue Swirl
2010-05-13 19:40     ` Jan Kiszka [this message]
2010-05-12 21:19 ` [Qemu-devel] [PATCH 4/6] serial: Register vmstate via qdev Jan Kiszka
2010-05-12 21:19 ` [Qemu-devel] [PATCH 5/6] fdc: " Jan Kiszka
2010-05-12 21:19 ` [Qemu-devel] [PATCH 6/6] mc146818rtc: " Jan Kiszka
2010-05-12 22:49 ` [Qemu-devel] Re: [PATCH 0/6] vmstate: Drop post_save / allow instance ID aliases Juan Quintela

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=4BEC55BB.7060503@web.de \
    --to=jan.kiszka@web.de \
    --cc=blauwirbel@gmail.com \
    --cc=jan.kiszka@siemens.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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).