qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH RFC v6 18/20] virtio: support revision-specific features
Date: Fri, 30 Jan 2015 15:08:08 +0100

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.

I've hacked up something and will play with it a bit; I might post a
new patch series next week.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]