On Mon, Sep 09, 2019 at 03:05:08PM +0200, Johannes Berg wrote: > On Mon, 2019-09-09 at 08:41 -0400, Michael S. Tsirkin wrote: > > > > The only thing we could do is crash if it wants to use this feature > > > without the others, but would that really be helpful? > > > > We can return failure from SET_PROTOCOL_FEATURES. > > We can also fail all following messages. > > Only if we have F_REPLY_ACK, I think? > > 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. > 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 > and add some text that tells a device > how to behave when F_KICK_CALL_MSGS is negotiated without F_REPLY_ACK? > > johannes We can document how to behave in case of inconsistent protocol features, yes.
