From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 5254B2935 for ; Fri, 28 Apr 2017 10:04:27 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2017 01:04:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,387,1488873600"; d="scan'208";a="95213138" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga006.fm.intel.com with ESMTP; 28 Apr 2017 01:04:23 -0700 Date: Fri, 28 Apr 2017 16:00:44 +0800 From: Yuanhan Liu To: Maxime Coquelin Cc: Zhiyong Yang , dev@dpdk.org, ciara.loftus@intel.com, =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , "Michael S. Tsirkin" Message-ID: <20170428080044.GX11512@yliu-dev.sh.intel.com> References: <1493274893-40764-1-git-send-email-zhiyong.yang@intel.com> <57212715-6192-dba2-418a-2418a5d14953@redhat.com> <20170427082047.GL11512@yliu-dev.sh.intel.com> <0bb0c833-1178-c587-8085-12137ebd91d5@redhat.com> <20170428022558.GM11512@yliu-dev.sh.intel.com> <9ecbbd0b-a2a0-7674-e84d-c8beeeeff0e6@redhat.com> <20170428073553.GV11512@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH] vhost: fix MQ fails to startup X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 08:04:27 -0000 On Fri, Apr 28, 2017 at 09:57:20AM +0200, Maxime Coquelin wrote: > >>>Maybe we could introduce a version message? With that, we could tell > >>>whether the frontend has fixed the known bug or not. > >> > >>That's a possibility, but this is not really the role of a protocol > >>version. As in this case, the protocol does not change, just an > >>implementation. > > > >Maybe. Well, you might could think this way: we do increase the version > >when we make a new release (with bugs being fixed). > > > >Or, we could also make the version two parts: major and minor. We increase > >major for major updates (say, new features, etc). We increase minor for > >bug fixes. > > > >The only thing that doesn't make too much sense is the bug is actually > >from the QEMU implementation but not from the vhost-user spec. > > Yes, I was maybe not clear, but that's what I meant when saying that was > not the role of the protocol version. Yes, I realized it later: I overlooked it. Sorry. > >Talking > >about that, it may make more sense to introduce a new message to carry > >the frontend version, something like a string "QEMU v2.8". > > I don't think this is a good idea as it would create more problems that it > would solve. Indeed, you would need also the distro version, as for > example, Red Hat could backport the fix in its QEMU v2.6 package, Ubuntu > in its v2.7, etc... I have thought of stable release, say "QEMU v2.8.1". But you are right, it got way more complex when distro backport is considered :( --yliu