From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yuanhan Liu Subject: Re: [PATCH] vhost: fix MQ fails to startup Date: Fri, 28 Apr 2017 16:00:44 +0800 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 Cc: Zhiyong Yang , dev@dpdk.org, ciara.loftus@intel.com, =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , "Michael S. Tsirkin" To: Maxime Coquelin 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) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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