Re: [hatari-devel] Release time for 1.8.1 ?

[Steven Noonan <steven@xxxxxxxxxxxxxx>]

On Fri, May 8, 2015 at 1:31 PM, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:
> Le 07/05/2015 22:27, Eero Tamminen a écrit :
>>
>> Hi,
>>
>> On torstai 07 toukokuu 2015, Nicolas Pomarède wrote:
>>>
>>> It's not always easy to decide why such version had a big number change,
>>> and other only a minor. But I really want to keep 1.9 and 2.0 for major
>>> releases with huge changes (for example : full cpu switch to winuae,
>>> full rewrite of the shifter emulation, full switch to sdl2, ...)
>>
>>
>> There's nothing preventing us from having 1.10, 1.11 etc before 2.0.
>> Hatari's v2.0 release could even be reserved just for SDL2 switch as it's
>> a
>> large dependency change, and version numbers match...
>>
>> On Linux kernel side, change from 3.19 to 4.0 was no bigger than change
>> from
>> 3.18 to 3.19. :-)
>>
>
>
> Hi
>
> I thought about using 1.9.0, 1.10.0, 1.11.0, .. too, but as Thomas wrote the
> version if of the form "x.y.z\0" and it's kinda hardcoded in
> memorysnapshot.c to take 6 bytes when saving/restoring, so using 1.10.0 for
> example would take 7 bytes in the memory snapshot header, which might not be
> correctly handled (we need to handle the case where an older Hatari version
> will load a more recent snapshot and should tell it's not compatible).
>
> If we can update the use of VersionString in MemorySnapShot_OpenFile to work
> with more than 6 bytes of ident string, then I think we can use 1.9.0 for
> next version, then 1.10.0, 1.11.0, ...
>

Hmm, I'm not sure I agree with the "6 vs 7 bytes is a problem"
argument. Yes, it's a true statement if you are only considering
snapshot portability between different Hatari versions. I'll grant
that.

But I think snapshots really need an overhaul for correctness reasons
-- for example if you save the memory state in a 64-bit build of
Hatari and try to load it in a 32-bit build of Hatari, it won't work
(usually by crashing) because it serialized a bunch of 64-bit pointers
to disk and the structure offsets of the state on disk are all wrong.
In my opinion, the whole "fwrite() all your in-memory structures to a
file" is a poor design.

There are even some issues with saving/restoring snapshots going from
Hatari 32-bit x86 to Hatari using the Linux x32 ABI (basically full
x86_64 but with 32-bit pointers). This *should* be totally compatible
because the pointer sizes are the same, and thus all the structure
sizes should be identical. However, some of the structure packing is
different between the two builds which causes memory state
save/restore to break. I fixed a few of these issues in my local repo,
but haven't submitted changes to the list.

There are also problems trying to move snapshots between different
architectures. e.g. 32-bit x86 snapshot will have different endianness
than a 32-bit PowerPC snapshot. So endianness needs normalization too.

I've been playing with some ideas to use something like protobuf-c or
msgpack-c for portable and compact memory state save/restore, but I
haven't touched it in a while. Of the two options, msgpack felt like
the easiest and simplest approach. The serialization API for msgpack-c
is quite pleasant and is code size friendly, but the deserialization
side wasn't nearly as simple just because of the msgpack-c API design.
Perhaps there's an alternative I haven't looked at yet.