Re: [PATCH v5] introduce vfio-user protocol specification

[John Levon <levon@movementarian.org>]

On Mon, Nov 02, 2020 at 11:29:23AM +0000, Thanos Makatos wrote:

> > +==============+========+=================================
> > ==================+
> > > | version      | object | ``{"major": <number>, "minor": <number>}``        |
> > > |              |        |                                                   |
> > > |              |        | Version supported by the sender, e.g. "0.1".      |
> > 
> > It seems quite unlikely but this should specify it's strings not floating point
> > values maybe?
> > 
> > Definitely applies to max_fds too.
> 
> major and minor are JSON numbers and specifically integers.

It is debatable as to whether there is such a thing as a JSON integer :)

> The rationale behind this is to simplify parsing. Is specifying that
> major/minor/max_fds should be an interger sufficient to clear any vagueness
> here?

I suppose that's OK as long as we never want a 0.1.1 or whatever. I'm not sure
it simplifies parsing, but maybe it does.

> > > Versioning and Feature Support
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > Upon accepting a connection, the server must send a VFIO_USER_VERSION
> > message
> > > proposing a protocol version and a set of capabilities. The client compares
> > > these with the versions and capabilities it supports and sends a
> > > VFIO_USER_VERSION reply according to the following rules.
> > 
> > I'm curious if there was a specific reason it's this way around, when it seems
> > more natural for the client to propose first, and the server to reply?
> 
> I'm not aware of any specific reason.

So can we switch it now so the initial setup is a send/recv too?

thanks
john