> -----Original Message----- > From: John Levon <[email protected]> > Sent: 07 November 2020 12:26 > To: John G Johnson <[email protected]> > Cc: Thanos Makatos <[email protected]>; > [email protected]; Elena Ufimtseva > <[email protected]>; [email protected]; > [email protected]; [email protected]; Swapnil Ingle > <[email protected]>; [email protected]; > [email protected]; [email protected]; qemu- > [email protected]; [email protected]; [email protected]; > [email protected]; Stefan Hajnoczi <[email protected]>; > Felipe Franciosi <[email protected]>; [email protected]; Marc-André > Lureau <[email protected]>; Raphael Norwitz > <[email protected]>; [email protected]; > [email protected] > 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
