[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 00/20] VMState: port all i2c devices
From: |
Juan Quintela |
Subject: |
[Qemu-devel] Re: [PATCH 00/20] VMState: port all i2c devices |
Date: |
Mon, 14 Sep 2009 00:35:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
<address@hidden> 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.
- [Qemu-devel] [PATCH 10/20] vmstate: port pxa2xx_i2c device, (continued)
- [Qemu-devel] [PATCH 10/20] vmstate: port pxa2xx_i2c device, Juan Quintela, 2009/09/11
- [Qemu-devel] [PATCH 13/20] tmp105: change len and alorm to uint8_t, Juan Quintela, 2009/09/11
- [Qemu-devel] [PATCH 14/20] vmstate: port wmp105 device, Juan Quintela, 2009/09/11
- [Qemu-devel] [PATCH 16/20] vmstate: port twl92230 device, Juan Quintela, 2009/09/11
- [Qemu-devel] [PATCH 17/20] vmstate: add support for arrays of pointers, Juan Quintela, 2009/09/11
- [Qemu-devel] [PATCH 19/20] vmstate: port lm832x device, Juan Quintela, 2009/09/11
- [Qemu-devel] [PATCH 11/20] vmstate: port ssd0303 device, Juan Quintela, 2009/09/11
- Re: [Qemu-devel] [PATCH 00/20] VMState: port all i2c devices, Juha.Riihimaki, 2009/09/11
- [Qemu-devel] [PATCH 15/20] twl92230: change pwrbtn_state to uint8_t, Juan Quintela, 2009/09/11
- [Qemu-devel] [PATCH 20/20] vmstate: remove i2c_slave_load/save, Juan Quintela, 2009/09/11
- [Qemu-devel] [PATCH 18/20] lm832x: make fields to have the same types that they are saved/loaded, Juan Quintela, 2009/09/11