On Tue, Feb 26, 2019 at 10:09:19AM +0100, Markus Armbruster wrote: > Stefan Hajnoczi <stefa...@redhat.com> writes: > > On Mon, Feb 25, 2019 at 10:28:46AM +0100, Peter Krempa wrote: > >> On Mon, Feb 25, 2019 at 09:50:26 +0100, Markus Armbruster wrote: > >> > Stefan Hajnoczi <stefa...@redhat.com> writes: > >> Other than the above, this is a welcome improvement as I've personally > >> ran into scenarios where a feature in qemu was fixed but it was > >> impossible to detect whether given qemu version contains the fix as it > >> did not have any influence on the QMP schema. > > > > I'd like to make things as simpler as possible, but no simpler :). > > > > The simplest option is that the advertised features are set in stone at > > build time (e.g. selected with #ifdef if necessary). But then we have > > no way of selecting features at runtime (e.g. based on kernel features). > > > > What do you think? > > I think we should map the problem space, identify cases with actual > uses, then design a solution that covers them and can plausibly grow to > cover cases we anticipate. > > The migrate-with-cache-direct-off-on-linux case is compile-time static. > > Do we have or have we had a case that is not compile-time static?
I can't think of something that both requires query-qemu-features and isn't compile-time static. But that could be because not many things require query-qemu-features :). The philosophy on Linux seems to be: distros compile QEMU against headers that accurately reflect the system features that are available. Therefore there isn't a lot of runtime fallback logic in case a new QEMU is running on an old host. This means we can get by with compile-time static features only. One possible exception is the ENOSYS/ENOTSUP fallback code in block/file-posix.c:handle_aiocb_write_zeroes() and handle_aiocb_copy_range(). Stefan
signature.asc
Description: PGP signature
