Re: [Qemu-devel] [PULL 8/9] static checker: e1000-82540em got aliased to e1000

[Jason Wang <jasowang@redhat.com>]

On 02/22/2016 08:39 PM, Amit Shah wrote:
> On (Thu) 11 Feb 2016 [14:04:06], Paolo Bonzini wrote:
>>
>> On 05/02/2016 14:56, Amit Shah wrote:
>>> Commit 8304402033e8dbe8e379017d51ed1dd8344f1dce changed the name of the
>>> e1000-82540em device to e1000.  This was flagged:
>>>
>>>    Section "e1000-82540em" does not exist in dest
>>>
>>> Add the mapping to the changed section names dictionary so the checker
>>> can proceed.
>>>
>>> Signed-off-by: Amit Shah <amit.shah@redhat.com>
>>> Acked-by: Jason Wang <jasowang@redhat.com>
>>> Message-Id: <7ccfe834c897142dceaa4da87c13b7059fa12aa8.1450416947.git.amit.shah@redhat.com>
>>> Signed-off-by: Amit Shah <amit.shah@redhat.com>
>>> ---
>>>  scripts/vmstate-static-checker.py | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/scripts/vmstate-static-checker.py b/scripts/vmstate-static-checker.py
>>> index b6c0bbe..b5ecaf6 100755
>>> --- a/scripts/vmstate-static-checker.py
>>> +++ b/scripts/vmstate-static-checker.py
>>> @@ -99,6 +99,7 @@ def get_changed_sec_name(sec):
>>>      # Section names can change -- see commit 292b1634 for an example.
>>>      changes = {
>>>          "ICH9 LPC": "ICH9-LPC",
>>> +        "e1000-82540em": "e1000",
>>>      }
>>>  
>>>      for item in changes:
>>>
>> This means that 2.5 cannot migrate 2.4 virtual machines, right?  Is that
>> something we want to rectify in 2.6 by making e1000-82540em an alias of
>> e1000 (instead of the other way round)?
> You're right; I misread it.  With that commit (8304402033):
>
> 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em.
>
> This is despite they're aliased (so the cmdline is backward
> compatible), but the migration device name actually changed.
>
> Of course, 2.5->2.4 will also not work.
>
> Since 2.4 emits 'e1000-82540em' as the device name in the migration
> stream, and 2.5 emits just 'e1000', we have two different names for
> the same device in two versions.
>
> To fix this, we'll need a hack on the dest side to allow e1000 and
> e1000-82540em in the migration stream for the device, and this can be
> done for 2.6 and 2.5.stable.
>
> Jason, can you attempt this?
>
>
> 		Amit

Sure, but just need to understand the "problem". If I understand this
correctly, the issue only happen for JSON description at the end of
migration stream, and it won't break migration in fact?