On Fri, 2018-10-05 at 12:10 +0100, Daniel P. Berrangé wrote: > On Fri, Oct 05, 2018 at 12:33:57PM +0200, Jiri Denemark wrote: > > OK, but if it's us choosing some default which QEMU considers > > deprecated, it's us who should dealt with it. That is, change the > > default IMHO. Sure apps could just stop relying on defaults and choose > > something specific which is not deprecated, but that doesn't mean we as > > a user of QEMU should continue using default values which got deprecated > > and are likely to be removed. > > > > If it's something which is not user/guest visible, we are already trying > > to move to more modern interfaces. That is easy since it doesn't change > > anything for libvirt users, but I feel like we need to have a plan for > > stuff which actually is visible to our users. > > If some user visible feature is actually removed, then our hand is > forced - we have to pick something else to replace it. This is what > happened with the default NIC with RHEL stopped building rtl8139, > so we had to have a default fallback. > > That change is/was not seemless since there exist OS which supported > rtl8139 but which lacked e1000 / virtio-net drivers. Fortunately apps > already use libosinfo to explicitly set NIC model so the breakage was > not so visible. > > If 'i440fx' is ever actually deleted we would have todo something > similar - prefer i440fx for best historical compat, but fallback > to q35 despite knowing it could break. I think this is just running in circles around the issue. Once you've determined that there is no sensible default that works for everyone, and that whatever works now might not work in the future, so applications should provide a value instead of relying on the default if they don't want to break down the line, you've made the default for all intents and purposes entirely pointless. Yet you've stopped just short of actually addressing the underlying issue, which you would do by (after a generous deprecation period) *requiring* applications to provide an explicit value at all times. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
