On Mon, Sep 09, 2019 at 03:50:48PM +0200, Johannes Berg wrote:
> On Mon, 2019-09-09 at 09:48 -0400, Michael S. Tsirkin wrote:
>
> > > I suppose we could fail a later command that already needs a reply
> > > without REPLY_ACK, but that seems difficult to debug?
> >
> > Next command is GET_FEATURES. Return an error response from that
> > and device init will fail.
>
> Hmm, what's an error here though? You can only return a value, no?
Either returning id that does not match GET_FEATURES or
returning size != 8 bytes will work.
Using 0 size payload has precedent in VHOST_USER_GET_CONFIG:
vhost-user slave uses zero length of
payload to indicate an error to vhost-user master.
It's annoying that we don't get an error indicator in that case though.
Worth returning e.g. a 4 byte code?
And let's generalize for all other messages with response?
> > > Anyway, if you feel that we should have this as some sort of safeguard I
> > > can try to do that; to me it feels rather pointless as libvhost-user is
> > > more of a sample implementation than anything else.
> >
> > Exactly for this reason :)
>
> :)
>
> > > Unless you also wanted to write into the spec that F_KICK_CALL_MSGS
> > > absolutely *requires* F_REPLY_ACK,
> >
> > yep
>
> Sure, I'm fine with that.
>
> > We can document how to behave in case of inconsistent protocol features,
> > yes.
>
> OK.
>
> johannes
