From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8w0D-0001s6-MQ for qemu-devel@nongnu.org; Wed, 07 Jan 2015 14:10:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y8w08-0002yO-Od for qemu-devel@nongnu.org; Wed, 07 Jan 2015 14:10:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8w08-0002xY-Cw for qemu-devel@nongnu.org; Wed, 07 Jan 2015 14:10:40 -0500 Date: Wed, 7 Jan 2015 21:10:07 +0200 From: "Michael S. Tsirkin" Message-ID: <20150107191006.GB8734@redhat.com> References: <1418304322-7546-1-git-send-email-cornelia.huck@de.ibm.com> <1418304322-7546-19-git-send-email-cornelia.huck@de.ibm.com> <20141228083206.GA6802@redhat.com> <20150107172232.57cbeb31.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150107172232.57cbeb31.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH RFC v6 18/20] virtio: support revision-specific features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: thuth@linux.vnet.ibm.com, rusty@rustcorp.com.au, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org On Wed, Jan 07, 2015 at 05:22:32PM +0100, Cornelia Huck wrote: > On Sun, 28 Dec 2014 10:32:06 +0200 > "Michael S. Tsirkin" wrote: > > > On Thu, Dec 11, 2014 at 02:25:20PM +0100, Cornelia Huck wrote: > > > Devices may support different sets of feature bits depending on which > > > revision they're operating at. Let's give the transport a way to > > > re-query the device about its features when the revision has been > > > changed. > > > > > > Signed-off-by: Cornelia Huck > > > > So now we have both get_features and get_features_rev, and > > it's never clear which revision does host_features refer to. > > IMHO that's just too messy. > > Let's add get_legacy_features and host_legacy_features instead? > > I wanted to avoid touching anything that does not support version 1. > And this interface might still work for later revisions, no? We can add _modern_ then, or rename host_features to host_legacy_features everywhere as preparation. -- MST