qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/6] vmstate: Add support for alias ID


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 3/6] vmstate: Add support for alias ID
Date: Thu, 13 May 2010 21:40:43 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Blue Swirl wrote:
> On 5/13/10, Jan Kiszka <address@hidden> wrote:
>> From: Jan Kiszka <address@hidden>
>>
>>  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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]