search for: get_features_legacy

...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 implementatio...

...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 implementatio...

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" <mst at redhat.com> 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

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" <mst at redhat.com> 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

...port 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...

...port 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...