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
