From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YI25H-0004fE-H4 for qemu-devel@nongnu.org; Sun, 01 Feb 2015 16:29:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YI25E-0003em-BH for qemu-devel@nongnu.org; Sun, 01 Feb 2015 16:29:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YI25E-0003eh-4R for qemu-devel@nongnu.org; Sun, 01 Feb 2015 16:29:32 -0500 Date: Sun, 1 Feb 2015 23:29:20 +0200 From: "Michael S. Tsirkin" Message-ID: <20150201212919.GB9804@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> <20150107191006.GB8734@redhat.com> <20150130150808.007c6572.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150130150808.007c6572.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 Fri, Jan 30, 2015 at 03:08:08PM +0100, Cornelia Huck wrote: > On Wed, 7 Jan 2015 21:10:07 +0200 > "Michael S. Tsirkin" wrote: > > > 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. > > > > OK, I've ditched the "don't modify old stuff" goal and introduced > ->get_features_legacy(). For now, devices will add VERSION_1 in their > ->get_features() callback when they support it. (For many devices, this > will be the only difference between the two callbacks.) > > Two sets of host_features don't make much sense to me. It's the most natural implementation given that some features are only set for legacy and some (will be) only for modern interfaces. But we'll see. > I've hacked up something and will play with it a bit; I might post a > new patch series next week.