qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures
Date: Fri, 17 Mar 2017 10:12:57 +0000	[thread overview]
Message-ID: <20170317101257.GB8050@redhat.com> (raw)
In-Reply-To: <7e86352b-add7-7b73-4e6b-08016b3e7a5d@redhat.com>

On Fri, Mar 17, 2017 at 10:09:51AM +0100, Thomas Huth wrote:
> On 16.03.2017 17:52, Paolo Bonzini wrote:
> > 
> > 
> > On 16/03/2017 16:55, Peter Maydell wrote:
> >>> IOW, I think there is a reasonable 3 tier set here
> >>>
> >>>  1. Stuff we actively test builds & thus guarantee will work for
> >>>     any QEMU release going forward.
> >>>
> >>>  2. Stuff we don't actively test, but generally assume is mostly
> >>>     working, and likely to be fixed if & when problems are found
> >>>
> >>>  3. Stuff we don't actively test,  assume is probably broken
> >>>     and unlikely to be fixed if reported
> >>>
> >>> Stuff in tier 3 should be candidate for deletion. Stuff in tier
> >>> 2 shouldn't be removed, but it might drop into tier 3 at some
> >>> point if people stop caring about fixing problems when found.
> >>> Conversely tier 2 might rise to tier 1 if CI turns up.
> >>
> >> I don't really want a tier 2. Either we support it enough
> >> to at least be able to run "make && make check" on some
> >> representative system, or we don't support it at all.
> >> Code which we have but are really reluctant to touch because
> >> we don't even test it builds (like bsd-user/) is really bad
> >> for preventing cleanups.
> > 
> > I think we should further differentiate between bsd-user/ and softmmu.
> > System emulation is just another program where we mostly compile to C
> > standard + POSIX or C standard + Win32.  There are certainly places
> > where we use Linux-specific extensions but it's not that special.
> > Neither BSD nor Solaris are particularly hard to support there.
> > 
> > On the other hand, bsd-user is extremely BSD specific, and ought to have
> > CI.  I think there should be a tier 2 for system emulation (which
> > doesn't mean that anything there shouldn't be moved to tier 3 and
> > eventually removed), but there shouldn't be a tier 2 for user-mode
> > emulation.
> > 
> > In particular, I believe that we should remove bsd-user from 2.10 unless
> > the downstream BSD port is merged back (and CI is provided).  There is
> > no point in keeping the current half-baked code without thread support.
> 
> I think you made a good point here.
> So "+1" from my side to remove "bsd-user" and "tcg/ia64" in QEMU 2.10
> or 2.11 (unless someone speaks up and provides maintainence, of course).

In the mail thread two months back Sean Bruno did suggest he might like
to just start over with bsd-user:

  https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00171.html

So perhaps someone should just ping him to see if he objects to us
deleting bsd-usr now (on off chance he's got patches nearly ready to
fix it)

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

  reply	other threads:[~2017-03-17 10:13 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 [this message]
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 ` [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures Knut Omang
2017-03-25 21:15   ` 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=20170317101257.GB8050@redhat.com \
    --to=berrange@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --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 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).