All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2
Date: Wed, 12 Jul 2017 17:12:54 +0100	[thread overview]
Message-ID: <20170712161254.GJ5237@redhat.com> (raw)
In-Reply-To: <9d51d348-7ad6-a98d-3f6d-89e8af5e3a16@redhat.com>

On Wed, Jul 12, 2017 at 06:00:46PM +0200, Thomas Huth wrote:
> On 12.07.2017 17:04, Daniel P. Berrange wrote:
> > On Wed, Jul 12, 2017 at 10:22:33AM +0200, Thomas Huth wrote:
> >> We don't want to carry along old machine types forever. If we are able to
> >> remove the pc machines up to 0.13 one day for example, this would allow
> >> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> >> BARs directly to low memory). Everything up to pc-1.2 is also known to
> >> have issues with migration.  So let's start with a deprecation message
> >> for the old machine types so that the (hopefully) few users of these old
> >> systems start switching over to newer machine types instead.
> > 
> > I think we must document & agree on our support policy for machine
> > types, before we start marking them as deprecated. eg please consider
> > the following document before accepting this deprecation patch:
> > 
> >  https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00652.html
> > 
> > Note in that proposal there, I say we do *not* go through trouble of
> > explicitly marking machines as deprecated. We just document upfront
> > the intended lifecycle and then delete them when it is done.
> > 
> > Just use deprecation warnings for things where there is no predictable
> > lifecycle upfront.
> 
> I'm still not 100% sure whether that auto-deprecation of machine types
> is such a good idea ... since we might need to maintain machines in
> downstream a little bit longer than specified there, it might be better
> to rather deprecate them manually from time to time.

Downstreams usually maintain custom machine types, so fact that the
upstream machine types get deleted is not a problem in itself. The problem
comes if followup internal code removal then prevents downstream from
creating their custom machine type.  I don't think we need tie these
issues together. We can remove old machine types, without immediately
removing features that our harm creation of downstream machine types.

> Anyway, concerning my patch - I'll stop here and won't send another
> version. There is too much bikeshed painting going on in this area for
> my taste, and since I'm rather a powerpc / s390x guy, I'm also fine if
> the pc-0.x machines stay around forever. If somebody else wants to push
> this topic instead, feel free to do so.

FWIW, I think your proposals have been very useful in general. It has
been way overdue to have this kind of discussion. I just want us to
focus on defining a policy, rather than making adhoc decisions each
time around, as the later is rather unpredictable for users of qemu.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2017-07-12 16:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-12  8:22 [Qemu-devel] [PATCH v3] hw/i386: Deprecate the machines pc-0.10 to pc-1.2 Thomas Huth
2017-07-12 13:31 ` Gerd Hoffmann
2017-07-12 14:51 ` Eduardo Habkost
2017-07-12 15:17   ` Michael S. Tsirkin
2017-07-12 20:15     ` Eduardo Habkost
2017-07-12 20:31       ` Michael S. Tsirkin
2017-07-12 20:56         ` Eduardo Habkost
2017-07-12 22:27           ` Michael S. Tsirkin
2017-07-13  0:23             ` Laszlo Ersek
2017-07-13  0:45               ` Michael S. Tsirkin
2017-07-13  0:47               ` Michael S. Tsirkin
2017-07-13 15:17               ` Eduardo Habkost
2017-07-13 15:34                 ` Laszlo Ersek
2017-07-13 22:41                 ` Michael S. Tsirkin
2017-07-14 15:40                   ` Eduardo Habkost
2017-07-13 15:24       ` Eric Blake
2017-07-12 15:45   ` Markus Armbruster
2017-07-12 17:48     ` Eduardo Habkost
2017-07-12 15:04 ` Daniel P. Berrange
2017-07-12 16:00   ` Thomas Huth
2017-07-12 16:12     ` Daniel P. Berrange [this message]
2017-07-12 16:23       ` Thomas Huth
2017-07-12 16:32         ` Daniel P. Berrange
2017-07-12 16:23       ` Paolo Bonzini
2017-07-12 16:29         ` Daniel P. Berrange
2017-07-12 20:37           ` Eduardo Habkost
2017-07-13 23:14           ` Michael S. Tsirkin
2017-07-14 16:33             ` Eduardo Habkost
2017-07-12 20:26   ` Eduardo Habkost
2017-07-13  0:30 ` Laszlo Ersek
2017-07-13  0:47   ` Michael S. Tsirkin
2017-07-13  1:02     ` Laszlo Ersek
2017-07-13  1:00 ` Michael S. Tsirkin
2017-07-13 15:20   ` Eduardo Habkost
2017-07-13 23:04     ` Michael S. Tsirkin
2017-07-14  5:37       ` Thomas Huth
2017-07-14  9:50       ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170712161254.GJ5237@redhat.com \
    --to=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.