Hi, > > With a feature flag both driver and device can choose whenever they want > > support v1 or v2 or both. With a version config field this is more > > limited, the device can't decide to support both. So the bonus points > > for a smooth transition go to the feature flags not the version field ;) > > I agree that feature flags would be preferable in general, but I'm > concerned by the fact that there is (IIUC) a limited number of them. We have 64 total, some reserved, 24 are available to devices right now, see https://www.kraxel.org/virtio/virtio-v1.1-cs01-video-v3.html#x1-130002 > Video tends to change significantly over time, and to have optional > features that would also be presented as feature flags. After a while > we may run out of them, while a new protocol version would allow us to > extend the config struct with some new flags. Or am I missing > something? Not everything needs a feature flag. For example we have VIRTIO_VIDEO_CMD_QUERY_CAPABILITY, and we can add new video formats without needing a feature flag. Maybe it is a good idea to explicitly say in the specs that this can happen and that the driver should simply ignore any unknown format returned by the device. > I also wonder how "support v1 or v2 or both" would work with feature > flags. In order to make it possible to opt out of v1, I guess we would > need "v1 supported" flag to begin with? The driver can ignore any device without v2 feature flag set. The device can refuse to accept a driver without v2 support (don't allow setting the FEATURES_OK bit). A explicit v1 feature flag would allow the guest driver print a more specific error message ("device doesn't support v1" instead of "feature negotiation failed"), but that's it. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel