On Thu, Dec 17, 2015 at 12:36:11PM -0500, John Snow wrote: > > > On 12/17/2015 12:27 PM, Eduardo Habkost wrote: > > Migration with q35 was not possible before commit > > 04329029a8c539eb5f75dcb6d8b016f0c53a031a, because q35 unconditionally > > creates an ich9-ahci device, that was marked as unmigratable. So all q35 > > machine classes before pc-q35-2.4 were not migratable, so there's no > > point in keeping compatibility code for them. > > > > Remove all old pc-q35 machine classes and keep only pc-q35-2.4. > > > > Signed-off-by: Eduardo Habkost <[email protected]> > > --- > > Resubmitting this series, as I didn't see any convincing argument > > to keep the old code around. > > --- > > hw/i386/pc_q35.c | 163 > > ------------------------------------------------------- > > 1 file changed, 163 deletions(-) > > [...] > > To recap, the main objection last time was that it might upset existing > libvirt configurations because libvirt saves the machine types in the > XML, and this will cause existing configurations to be unable to boot. > > There was some discussion over "fudging" it so that we silently forced > users onto 2.4+, but this was rejected as a bad idea in favor of just > simply breaking anybody relying on pre-2.4 machine types. > > So the question becomes: > > What do we gain by deleting this? Is cleaning up this code worth > breaking some configurations?
Developer time. We don't waste time reviewing, refactoring, and fixing compat code that nobody should ever run. See, for example, the patch sent by Gerd today: [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if not needed -- Eduardo
