qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 4/5] slirp: VMStatify socket level


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v4 4/5] slirp: VMStatify socket level
Date: Tue, 28 Feb 2017 17:09:26 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

* Samuel Thibault (address@hidden) wrote:
> Dr. David Alan Gilbert, on mar. 28 févr. 2017 17:00:17 +0000, wrote:
> > * Samuel Thibault (address@hidden) wrote:
> > > Dr. David Alan Gilbert, on mar. 28 févr. 2017 16:54:46 +0000, wrote:
> > > > I'm thinking one way to do it without changing the version would
> > > > be to use the existing value for IPv4, and on reading allow any other
> > > > value for IPv6 (or just the ones we know about); that would make
> > > > it inwards migration compatible.
> > > 
> > > Right. I don't know if that's enough for QEMU requirements.
> > 
> > If you change the version number you break backwards migration anyway;
> > but doing what I suggested would keep backwards working in most cases.
> 
> Sure, but in some cases we're breaking upward compatibility *silently*.

No, we don't need to break upwards compatibility; if I understand correctly
the only values that can be in that field at the moment are:
  AF_INET - IPv4 which is 2 on everything we've seen
  AF_INET6 - whose value is different on different implementations.

If we accept an incoming value of '2' to mean AF_INET then all existing
IPv4 connections work.
If we accept any other incoming value as AF_INET6 all existing IPv6 connections
work.
   - so that's foward compatibility OK.

If we generate '2' as the outgoing value for AF_INET then migration
to all exiting code works for IPv4; so backwards works for IPv4.
If we generate Linux's AF_INET6 number then IPv6 also works backwards
but only for Linux.

Dave

> Samuel
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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