> -----Original Message----- > From: John Levon <le...@movementarian.org> > Sent: 07 November 2020 12:26 > To: John G Johnson <john.g.john...@oracle.com> > Cc: Thanos Makatos <thanos.maka...@nutanix.com>; > benjamin.wal...@intel.com; Elena Ufimtseva > <elena.ufimts...@oracle.com>; tomassetti.and...@gmail.com; > jag.ra...@oracle.com; james.r.har...@intel.com; Swapnil Ingle > <swapnil.in...@nutanix.com>; yuvalkash...@gmail.com; > konrad.w...@oracle.com; kanth.ghatr...@oracle.com; qemu- > de...@nongnu.org; tina.zh...@intel.com; ism...@linux.com; > alex.william...@redhat.com; Stefan Hajnoczi <stefa...@redhat.com>; > Felipe Franciosi <fel...@nutanix.com>; xiuchun...@intel.com; Marc-André > Lureau <marcandre.lur...@redhat.com>; Raphael Norwitz > <raphael.norw...@nutanix.com>; changpeng....@intel.com; > dgilb...@redhat.com > Subject: Re: [PATCH v5] introduce vfio-user protocol specification > > On Thu, Nov 05, 2020 at 05:50:27PM -0800, John G Johnson wrote: > > > The idea behind the version IDs is to identify incompatible protocol > > changes as major versions, and compatible changes as minor versions. > What > > would be the purpose of the third version type? > > Well, like any patch version, it'd be for identifying versions on the other > side > for reporting, debugging purposes. Not imply anything about the protocol > version. But it's not a big deal. > > > The thing that makes parsing the JSON easier is knowing the version > > beforehand so the parser knows what keys to expect, so I’d like to > promote > > major and minor to separate fields in the packet from being embedded at > an > > arbitrary points in the JSON string. > > I agree that'd be a sensible change (and then I wonder if the little bit of > JSON > is actually useful any more).
The reason why the JSON string exists is that it simplifies adding information to the version, should we ever need to. > > > >> So can we switch it now so the initial setup is a send/recv too? > > > > > > I'm fine with that but would first like to hear back from John in case he > objects. > > > > > > I think I write that section, and just switched client and server. The > code > > is written as client proposes, server responds; this is the better model. > > Hah, great, thanks. > > regards > john
