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 --]
next prev parent 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).