A previous commit (3d4d16f4) added support for audio record/playback.
However this breaks the logfile ABI due to the re-ordering of the
ReplayEvents enum. The REPLAY_VERSION check is meant to prevent you
from using old log files in newer QEMUs but this is currently broken.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 replay/replay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/replay/replay.c b/replay/replay.c
index 78e2a7e570..9e0724e756 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -22,7 +22,7 @@
 
 /* Current version of the replay mechanism.
    Increase it when file format changes. */
-#define REPLAY_VERSION              0xe02005
+#define REPLAY_VERSION              0xe02006
 /* Size of replay log header */
 #define HEADER_SIZE                 (sizeof(uint32_t) + sizeof(uint64_t))
 
-- 
2.11.0

On 03/24/2017 10:26 AM, Alex Bennée wrote:
> A previous commit (3d4d16f4) added support for audio record/playback.
> However this breaks the logfile ABI due to the re-ordering of the
> ReplayEvents enum. The REPLAY_VERSION check is meant to prevent you
> from using old log files in newer QEMUs but this is currently broken.

As we don't have a formal release with the reordered enum yet, would an
alternative approach be partially reverting 3d4d16f4 to instead stick
the new enum values at the end, so that all existing enums are in the
same order?  Or do you still need the version bump even then, because
you don't want a new stream (with the new enums) being played to an
older system that isn't expecting them?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Eric Blake <eblake@redhat.com> writes:

> On 03/24/2017 10:26 AM, Alex Bennée wrote:
>> A previous commit (3d4d16f4) added support for audio record/playback.
>> However this breaks the logfile ABI due to the re-ordering of the
>> ReplayEvents enum. The REPLAY_VERSION check is meant to prevent you
>> from using old log files in newer QEMUs but this is currently broken.
>
> As we don't have a formal release with the reordered enum yet, would an
> alternative approach be partially reverting 3d4d16f4 to instead stick
> the new enum values at the end, so that all existing enums are in the
> same order?

That would certainly be an option.

> Or do you still need the version bump even then, because
> you don't want a new stream (with the new enums) being played to an
> older system that isn't expecting them?

I'm not personally bothered either way. Currently the check is a simple
match so there is not really the concept of a super/subsets of log file.

I only ran into this as I was trying to debug the record/replay
regression while writing a dumper script to debug the current
regression:

  https://github.com/stsquad/qemu/blob/mttcg/more-fixes-for-rc1-v2/scripts/replay-dump.py

--
Alex Bennée

Reviewed-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>


> -----Original Message-----
> From: Alex Bennée [mailto:alex.bennee@linaro.org]
> Sent: Friday, March 24, 2017 6:26 PM
> To: pavel.dovgaluk@ispras.ru
> Cc: qemu-devel@nongnu.org; Alex Bennée
> Subject: [PATCH-for-2.9] replay/replay.c: bump REPLAY_VERSION
> 
> A previous commit (3d4d16f4) added support for audio record/playback.
> However this breaks the logfile ABI due to the re-ordering of the
> ReplayEvents enum. The REPLAY_VERSION check is meant to prevent you
> from using old log files in newer QEMUs but this is currently broken.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  replay/replay.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/replay/replay.c b/replay/replay.c
> index 78e2a7e570..9e0724e756 100644
> --- a/replay/replay.c
> +++ b/replay/replay.c
> @@ -22,7 +22,7 @@
> 
>  /* Current version of the replay mechanism.
>     Increase it when file format changes. */
> -#define REPLAY_VERSION              0xe02005
> +#define REPLAY_VERSION              0xe02006
>  /* Size of replay log header */
>  #define HEADER_SIZE                 (sizeof(uint32_t) + sizeof(uint64_t))
> 
> --
> 2.11.0