From: Knut Omang <knut.omang@oracle.com>
To: Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures
Date: Sat, 25 Mar 2017 21:49:18 +0100 [thread overview]
Message-ID: <1490474958.11328.86.camel@oracle.com> (raw)
In-Reply-To: <CAFEAcA9pqDoCWrPAJ+KVxLC_eRy-xRg36oYuARYg2YP8VpGpBg@mail.gmail.com>
On Thu, 2017-03-16 at 15:23 +0000, Peter Maydell wrote:
> OK, here's a concrete proposal for deprecating/dropping out of
> date host OS and architecture support.
>
> We'll put this in the ChangeLog 'Future incompatible changes'
> section:
> -----
> * Removal of support for untested host OS and architectures:
>
> The QEMU Project intends to drop support in a future release for any
> host OS or architecture which we do not have access to a build and test
> machine for. This affects the following host OSes:
> * Native CYGWIN building
> * GNU/kFreeBSD
> * FreeBSD
> * DragonFly BSD
> * NetBSD
> * OpenBSD
> * Solaris
> * AIX
> * Haiku
> and the following host CPU architectures:
> * ia64
> * sparc
Can we please keep the Sparc support in for a while still?
There is an increasing recognition of the value of better support for
QEMU within Oracle and hopefully we can get some traction on this in not too
long.
I have colleagues currently looking at various ways forward
both in the direction of implementing support for newer Sparc architectures in
QEMU and also investigating support for native KVM support for Linux on Sparc.
When it comes to build platforms, a legitimate need to be able to keep anything
running, I don't have any authority to promise away hardware or other forms of
Sparc access, but I have been told that that part can be worked out in some way
if we get enough support for this internally.
Thanks,
Knut
> Specifically, if we do not have a build and test system available
> to us by the time we release QEMU 2.10, we will remove support in the
> release that follows 2.10.
> -----
>
> I'm not sure here if we want to just have this as a bald list,
> or to have some kind of two tier setup with OSes we expect to
> dump in one tier and OSes where we're really trolling for a build
> machine in the other tier (the "unlikely to dump" category would
> get most of the BSD variants in it). Putting out a changelog
> that says "we're gonna drop all the BSDs" seems like it might
> produce a lot of yelling?
>
> Should "native CYGWIN" be in the drop list? I only test
> mingw cross compile, but configure has a separate section for
> CYGWIN in its $targetos case statement.
>
> It would also not be too difficult to make configure warn when it
> is run on the deprecated OS or architecture, so we should probably
> sneak that into 2.9.
>
> (Technically right this instant 'mips' and 's390' would be in the
> 'dump' list, since I don't personally have access yet. But we have
> a plan for s390, and it turns out there is a mips machine in the
> gcc compile farm which I'm just checking out.)
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2017-03-25 20:49 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-16 15:23 [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures Peter Maydell
2017-03-16 15:46 ` Daniel P. Berrange
2017-03-16 15:55 ` Peter Maydell
2017-03-16 16:00 ` Daniel P. Berrange
2017-03-16 16:06 ` Peter Maydell
2017-03-16 16:12 ` Daniel P. Berrange
2017-03-17 9:09 ` Markus Armbruster
2017-03-16 16:52 ` Paolo Bonzini
2017-03-17 9:09 ` Thomas Huth
2017-03-17 10:12 ` Daniel P. Berrange
2017-03-17 10:15 ` Peter Maydell
2017-03-17 10:30 ` Thomas Huth
2017-03-17 10:48 ` Peter Maydell
2017-03-16 18:59 ` Dr. David Alan Gilbert
2017-03-17 9:58 ` Peter Maydell
2017-03-21 17:59 ` Eric Blake
2017-03-16 15:57 ` Gerd Hoffmann
2017-03-16 16:16 ` Daniel P. Berrange
2017-03-16 16:27 ` Peter Maydell
2017-03-16 18:01 ` Peter Maydell
2017-03-16 18:08 ` Daniel P. Berrange
2017-03-22 12:51 ` Alex Bennée
2017-03-22 13:09 ` Peter Maydell
2017-03-22 13:24 ` Thomas Huth
2017-03-23 10:33 ` Paolo Bonzini
2017-03-23 11:02 ` Peter Maydell
2017-03-24 1:28 ` Richard Henderson
2017-03-24 17:24 ` Peter Maydell
2017-03-22 19:07 ` [Qemu-devel] rawhide gcc failures [was: Proposal for deprecating unsupported host OSes & architecutures] Eric Blake
2017-03-22 19:39 ` Philippe Mathieu-Daudé
2017-03-27 6:36 ` Fam Zheng
2017-03-22 22:33 ` Peter Maydell
2017-03-23 9:25 ` Alex Bennée
2017-03-25 20:49 ` Knut Omang [this message]
2017-03-25 21:15 ` [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures Peter Maydell
2017-03-26 9:16 ` Knut Omang
2017-03-27 16:32 ` Peter Maydell
2017-03-28 18:34 ` Knut Omang
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=1490474958.11328.86.camel@oracle.com \
--to=knut.omang@oracle.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).