From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbjTO-0005xU-H9 for qemu-devel@nongnu.org; Tue, 15 Sep 2015 02:12:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbjKw-0000sj-ES for qemu-devel@nongnu.org; Tue, 15 Sep 2015 02:03:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbjKw-0000sd-7R for qemu-devel@nongnu.org; Tue, 15 Sep 2015 02:03:26 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id C2C56461D8 for ; Tue, 15 Sep 2015 06:03:25 +0000 (UTC) From: Markus Armbruster References: <1439939502-4722-1-git-send-email-ehabkost@redhat.com> <20150911184447.GE5920@thinpad.lan.raisama.net> <20150913121847-mutt-send-email-mst@redhat.com> <55F6E318.9020805@redhat.com> <20150914194313.GB18497@thinpad.lan.raisama.net> Date: Tue, 15 Sep 2015 08:03:23 +0200 In-Reply-To: <20150914194313.GB18497@thinpad.lan.raisama.net> (Eduardo Habkost's message of "Mon, 14 Sep 2015 16:43:13 -0300") Message-ID: <87oah49q38.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] q35: Remove old machine versions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Victor Kaplansky , "Michael S. Tsirkin" , Marcel Apfelbaum , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , John Snow , Paolo Bonzini , Laszlo Ersek Eduardo Habkost writes: > On Mon, Sep 14, 2015 at 09:09:12AM -0600, Eric Blake wrote: >> On 09/13/2015 03:28 AM, Michael S. Tsirkin wrote: >> > On Fri, Sep 11, 2015 at 03:44:47PM -0300, Eduardo Habkost wrote: >> >> Ping? >> >> >> >> So, what's the reason we are still keeping those old machines in the >> >> code? >> > >> > Victor also wanted to clean out some very old machine types for >> > the PIIX, too. >> > >> > But if someone created a machine with libvirt, these machine types >> > are now written in the XML. Failing to start guests isn't nice. >> >> New qemu with old libvirt isn't always guaranteed to work. And new >> libvirt can be patched to automatically update any old hard-coded >> machine name to a newer safe alternative, _when such update is proven >> safe_ (we've done it in the past for Fedora: if I recall correctly, >> Fedora 13 branched its own machine type, then in Fedora 15 qemu decided >> to quit supporting the branch, so libvirt was patched downstream in >> Fedora 15-17 to rewrite the old name into its safe upstream counterpart. >> The downstream patch was dropped in Fedora 18 since F15 was EOL by then >> so no more new machines would have been created with the old spelling, >> and since a year was deemed long enough for people to have either run >> their guest to pick up the automatic update, or that their guest was so >> infrequently run that they could read the error message and act on it >> themselves). >> >> Failing to start guests isn't nice, but it also isn't the end of the >> world, when there is no choice but to break ABI. An explicit ABI break >> (by making the user rewrite machine type) is better than silent change >> in behavior with a potential for broken guests. > > What I get from this, is that this is an user interface and usability > problem, and it's better to solve it at the appropriate layer (which is > not QEMU). > > If QEMU can't emulate those machines anymore, QEMU's job is to just tell > that to libvirt (so libvirt and management layers can decide what's the > best way to help the user cope with it), instead of lying to them and > say that we still emulate the same machine when we actually don't. Seconded. The story for direct use by humans is at least as convincing.