Re: [Qemu-devel] [PATCH RFC v6 18/20] virtio: support revision-specific features

[Michael S. Tsirkin]

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" <address@hidden> 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" <address@hidden> 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 <address@hidden>
> > > > 
> > > > 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.