Anthony Liguori <anth...@codemonkey.ws> wrote:
> On 03/23/2011 05:22 AM, Peter Maydell wrote:
>> On 23 March 2011 00:16, Anthony Liguori<aligu...@us.ibm.com> wrote:
>>> + if (old_version != new_version) {
>>> + g_error("Version %d of device `%s' is available in QEMU, but
>>> schema still reports %d, please update schema.\n",
>>> + new_version, device, old_version);
>>> + }
>> Might be nice for these "please update" error messages to
>> include a pointer to a docs file explaining in more detail
>> how to do that?
>> (also>80 char line ;-))
>
> Ack.
>
>>> diff --git a/vmstate/schema.json b/vmstate/schema.json
>>> new file mode 100644
>>> index 0000000..23483ab
>>> --- /dev/null
>>> +++ b/vmstate/schema.json
>>> @@ -0,0 +1,1176 @@
>>> +{
>>> + "cpu": {
>>> + "mcg_cap": "uint64",
>>> + "a20_mask": "int32",
>>> + "tsc_offset": "uint64",
>> This schema file appears to be board-specific (or at least
>> x86-specific) -- shouldn't the cpu/board/whatever name
>> be in the filename, so we have scope to expand the test
>> to checking migration issues for other platforms too?
>
> It's not really. Every VMStateDescription that is builtin into the
> tree is in the file.
>
> That said, the only target where the CPU is currently described by
> VMStateDescription is target-i386.
>
> Right now the file is generated via i386-softmmu. There may be a few
> devices left out because they are either not compiled into
> i386-softmmu or are target specific.
>
> We could complicate things further by trying to run against every
> target and then building a union of all target outputs but I'm not
> sure it's worth the effort at this stage.
>
>> (I don't care much about ARM migration breakages just at the
>> moment but I suspect that it will be becoming more important
>> by this time next year...)
>>
>> Also since this looks like an autogenerated file that's going
>> to be going into version control maybe it should have a
>> comment header at the top of the "autogenerated, do not edit
>> by hand!" type.
>
> JSON doesn't support comments.. I can add comment parsing to our
> parser though.
We need to fix the ordering problem.
Whatever schema we have should be good enough to allow:
- describe me this blob that contains the state for this device.
eepro100 at least is missing. Althought I would vote to just change the
eepro100 "naming" to always use eepro100 or similar, and remove the
current hack of having to change the vmstate->name for each different
device.
Later, Juan.
