On Thu, Feb 23, 2017 at 10:51:56AM +0000, Dr. David Alan Gilbert wrote: > Samual, Jan: Can you just take 1-3 of this series; 4 has a problem; > > * Juan Quintela (quint...@redhat.com) wrote: > > "Dr. David Alan Gilbert (git)" <dgilb...@redhat.com> wrote: > > > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > > > > > > Working up the stack, this replaces the slirp_socket_load/save > > > with VMState definitions. > > > > > > A place holder for IPv6 support is added as a comment; it needs > > > testing once the rest of the IPv6 code is there. > > > > > > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com> > > > > Reviewed-by: Juan Quintela <quint...@redhat.com> > > > > > > > +/* Win has a signed family number */ > > > +#define VMSTATE_SS_FAMILY(f, s) VMSTATE_INT16(f, s) > > > > Great! > > Just hope that there is no 32000 families soon :-) > > Actually; that's a problem; it turns out FreeBSD has a char for it's > family type rahter than the uint16 that linux and windows have. > I need to think hth to abstract that.
What, if any, promises have we made about the migration data format being ABI stable across platforms ? It strikes me that even if FreeBSD & Linux had the same sized type for ss_family, the constants used to popuate it might be different on each platform. eg AF_INET6 is 10 on Linux but 23 on Mingw and probably something else again on FreeBSD. IOW if we transmit this data on the wire, we've effectively said that our migration data format is *not* portable across different host OS platforms. At that point, sending different sized types on BSD vs Linux is no big deal since we're already incompatible semantically. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
