qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH] eepro100: Remove unused device status entries


From: Stefan Weil
Subject: [Qemu-devel] Re: [PATCH] eepro100: Remove unused device status entries
Date: Sat, 19 Sep 2009 17:58:20 +0200
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)

Juan Quintela schrieb:
> Stefan Weil <address@hidden> wrote:
>> A lot of entries are unused (they were added by copy + paste
>> from other drivers during development of eepro100.c).
>>
>> Removing them from nic_save, nic_load makes any
>> old saved status incompatible, so a new version
>> for the virtual machine data was needed, too.
>>
>> This patch is a step to synchronize my maintainer version
>> of eepro100.c (git://repo.or.cz/qemu/ar7.git) with the
>> version integrated in QEMU.
>>
>> +/* Parameters for nic_save, nic_load. */
>> +static const int eepro100_instance = -1;
>> +static const int eepro100_version = 20090807;
>
>
> Please, don't make version big numbers, idea is that versions are small
> numbers.
>
> Why do you want to be incompatible with the old saved state? We are
> going to big troubles to make everythnig backwards compatible, removing
> fields just makes everybody life worse. You can just rename as:
>
> s/foo/foo_dummy/ or /foo_vmstate/ and let it into the state.
>
> Later, Juan.

hi Juan

backward compatibility is ok for widely used features in stable software
releases,
and for a short moment I had thought about implementing it. Reading dummies
would have been sufficient (no need to keep dummies in the state).
But I decided against it.

I doubt that anybody is using saved machine states with eepro100 driver
data,
because those network cards are not QEMU's default, and they are still
unfinished.
So backward compatibility would have been an unnecessary burden here.
It is also better not to pretend that there is any backward compatibility
when it is nearly impossible to test this (and I am sure that there are
severe
faults in it).

My patch aims at finishing (or at least fixing and completing) this driver.
Some more patches are still needed for this goal (see my version on
repo.or.cz).

Personally, I prefer version numbers which express something, for example
the date of a change (as in my case). If it helps, I promise to send a patch
which sets the version number to 4 as soon as the rest of eepro100.c is ok.

Antony, please take the patch for now as it is, because I won't send a
new one
just to change the version number.

Regards

Stefan





reply via email to

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