[Qemu-devel] Re: [PATCH 00/20] VMState: port all i2c devices

[Juan Quintela <quintela@redhat.com>]

<Juha.Riihimaki@nokia.com> wrote:
> On Sep 11, 2009, at 13:47, ext Juan Quintela wrote:
>
>>>> - i2c->address now are uint8_t, my review of all uses is that they
>>>> are always
>>>> used as uint8_t (and that is the type that is passed on the
>>>> value).  If you know
>>>> i2c, please check.  Change 0002 looks big, but it is because as I  
>>>> was
>>>
>>> I would propose that the address has more than 8 bits to be more
>>> future-proof. After all, the bus addressing has already been extended
>>> to 10 bits: see http://www.i2c-bus.org/addressing/10-bit-addressing/
>>
>> Then we have a field day, and make incompatible versions from now on.
>> VMState use typechecking to make sure that what we save/load has the
>> same type that the variable.  And that was not the case for i2c
>> addresses.  how many users have old machines saved that they want to  
>> restore?
>
> I'm sorry but why is it not possible to start using e.g. 16 bits for  
> the address in the save states from now on and still keep the ability  
> to read save states generated with previous versions? I'm okay with  
> staying on 8 bit addresses only, I would just like to have some solid  
> rationale behind that decision.

It is possible in the Turing sense.  It is not possible in the current
VMSTate sense.

And it is not trivial to do it.  Only thing that I can think of is
passing  version_id to all get functions to be able to decide if address
is 8 bit or 16 bit address.  This get ugly fast.

The other solution that I can think of is adding address_vmstate that is
8 bits (current code), and a new one that is 16 bit.  I think this one
is a bit better (althought not perfect for any means).

In post_load, we do the adjustments (i.e. for older versions, we copy
the value to the new value.

It does'nt matter how we do it, fields changing size is never going to
be pretty.

Is 16 bits enough, or it is going to be needed to get more bits (there
are not so many address fields, getting them to 32bits shouldn't be such
a big deal.

Later, Juan.