From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 0A6BB9E3 for ; Fri, 28 Apr 2017 09:43:20 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2017 00:43:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,387,1488873600"; d="scan'208";a="1124360031" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga001.jf.intel.com with ESMTP; 28 Apr 2017 00:43:18 -0700 Date: Fri, 28 Apr 2017 15:39:38 +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: <20170428073938.GW11512@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: <20170428073553.GV11512@yliu-dev.sh.intel.com> 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 07:43:21 -0000 On Fri, Apr 28, 2017 at 03:35:53PM +0800, Yuanhan Liu 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. Nah, just forgot above two paragraphs, I overlooked it. You just need care the below one. --yliu > 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. 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".