[Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

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

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

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Daniel P. Berrange]

On Thu, Mar 16, 2017 at 03:23:45PM +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
> 
> 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?

I think it depends on the level of bit-rot we are aware of, and
whether we expect anyone is likely to fix the bit-rot should it
be discovered.

Simply not having a build machine for QEMU CI doesn't imply that
it is totally broken, and even if some pieces are broken, it
doesn't imply that QEMU is unusable.

e.g. if (hypothetically) QEMU fails to build when GNUTLS is enabled
on FreeBSD, that doesn't mean QEMU is unusable on FreeBSD - you
simply can't enable GNUTLS on that platform. If such breakage were
discovered, then I would also strive to fix it, despite not using
FreeBSD myself regularly.

In such a case ripping out all FreeBSD conditionals from the host
would be gratuitously unpleasant to our users. It is reasonable to
expect that someone will fix FreeBSD builds if & when bit-rot is
discovered. We're simply not able to guarantee the same level of
quality as our main tested platforms, at time of release.


Now, something like ia64 or sparc is probably a different matter.
While QEMU might again still be partially usable, even if some
bits are broken on ia64, the realistic likelihood of someone
caring enough to fix the ia64 builds at this point is effectively
zero.

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.

> 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.

Cygwin is different enough from mingw that I'd basically call
it a completely separate platform. IOW, successfull mingw
builds don't offer a strong guarantee of a succesfull cygwin
build.

> 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.

Good idea.

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/ :|

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 16 March 2017 at 15:46, Daniel P. Berrange <berrange@redhat.com> wrote:
> On Thu, Mar 16, 2017 at 03:23:45PM +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
>>
>> 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?
>
> I think it depends on the level of bit-rot we are aware of, and
> whether we expect anyone is likely to fix the bit-rot should it
> be discovered.
>
> Simply not having a build machine for QEMU CI doesn't imply that
> it is totally broken, and even if some pieces are broken, it
> doesn't imply that QEMU is unusable.

No, but it does imply that our CI is missing a big chunk.
Realistically, for the BSDs where I want to get to is "we
have BSD coverage in our CI setup". The problem at the moment
is that we (presumably) have BSD users but we have basically
no BSD developers active upstream, which in my view is not
a very long-term satisfactory situation.

> 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.

Right at the moment we effectively have something like these
three tiers -- to my mind the goal of the proposal is to
sort through all the stuff that's in tier 2 so we can either
push it up to tier 1 (if people surface who care enough to
help us maintain it) or push it down to tier 3 where we can
delete it.

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Gerd Hoffmann]

  Hi,

> 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?

Maybe we should have two levels of support.  Level one would be "machine
for test builds available", level two would be "someone looking after
it".

At least the freebsd guys have been posting patches to fix freebsd bugs
in the past.  Can't remember a recent post though, dunno whenever that
is because we didn't break anything or because they stopped bothering to
send their ports collection patches upstream.

usb-host support for bsd used to break now and then, but with the switch
to libusb that particular problem area went away a while back ...

cheers,
  Gerd

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Daniel P. Berrange]

On Thu, Mar 16, 2017 at 03:55:13PM +0000, Peter Maydell wrote:
> On 16 March 2017 at 15:46, Daniel P. Berrange <berrange@redhat.com> wrote:
> > On Thu, Mar 16, 2017 at 03:23:45PM +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
> >>
> >> 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?
> >
> > I think it depends on the level of bit-rot we are aware of, and
> > whether we expect anyone is likely to fix the bit-rot should it
> > be discovered.
> >
> > Simply not having a build machine for QEMU CI doesn't imply that
> > it is totally broken, and even if some pieces are broken, it
> > doesn't imply that QEMU is unusable.
> 
> No, but it does imply that our CI is missing a big chunk.
> Realistically, for the BSDs where I want to get to is "we
> have BSD coverage in our CI setup". The problem at the moment
> is that we (presumably) have BSD users but we have basically
> no BSD developers active upstream, which in my view is not
> a very long-term satisfactory situation.
> 
> > 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.

IMHO we should not be afraid of cleaning up code in such cases.
If bsd-user accidentally breaks because we clean up some other
parts of QEMU, so be it. If someone cares they'll step forward,
if not, it'll be a sign that it its material for tier 3 & thus
eventual removal.

I'm just pretty wary of gratuitously deleting stuff that still
has a reasonable chance of being functional, simply because
we lack CI testing.

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/ :|

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 16 March 2017 at 16:00, Daniel P. Berrange <berrange@redhat.com> wrote:
> I'm just pretty wary of gratuitously deleting stuff that still
> has a reasonable chance of being functional, simply because
> we lack CI testing.

Well, me too, but I think that if nobody turns up to help us
or donate a test machine despite configure yelling at them
for a release cycle or two then it's not all that gratuitous.

(Just for instance there's some grotty code in configure that
looks at 'uname -m' to guess what host OS it is, which is
really not the right way to do it. But I've never been able
to clean that up because maybe it might break something
semi obscure in the process.)

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Daniel P. Berrange]

On Thu, Mar 16, 2017 at 04:06:35PM +0000, Peter Maydell wrote:
> On 16 March 2017 at 16:00, Daniel P. Berrange <berrange@redhat.com> wrote:
> > I'm just pretty wary of gratuitously deleting stuff that still
> > has a reasonable chance of being functional, simply because
> > we lack CI testing.
> 
> Well, me too, but I think that if nobody turns up to help us
> or donate a test machine despite configure yelling at them
> for a release cycle or two then it's not all that gratuitous.
> 
> (Just for instance there's some grotty code in configure that
> looks at 'uname -m' to guess what host OS it is, which is
> really not the right way to do it. But I've never been able
> to clean that up because maybe it might break something
> semi obscure in the process.)

I'd just go ahead and clean it up regardless & let people report bugs, if
any.

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/ :|

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Daniel P. Berrange]

On Thu, Mar 16, 2017 at 03:23:45PM +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
> 
> 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.

BTW, by "build & test system available", presumably you mean a system
that someone has committed to actively maintaining, not merely donation
of (or access to) hardware on which to install & run VMs ?

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/ :|

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 16 March 2017 at 16:16, Daniel P. Berrange <berrange@redhat.com> wrote:
> BTW, by "build & test system available", presumably you mean a system
> that someone has committed to actively maintaining, not merely donation
> of (or access to) hardware on which to install & run VMs ?

My personal minimum is "something I can ssh into to run the build
scripts". Hardware maintained by somebody else is ideal (eg
anything in the gcc compile farm). I don't object to VMs as long
as somebody else is setting up and maintaining them...

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Paolo Bonzini]

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.

Paolo

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 16 March 2017 at 15:23, Peter Maydell <peter.maydell@linaro.org> wrote:
> (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.)

...unfortunately the gcc compile farm mips board (1) is very slow
and (2) has very little disk space free in /tmp, which means that
it can't pass "make check" because for instance tests/test-replication
assumes it can write comparatively large test files to /tmp/...

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Daniel P. Berrange]

On Thu, Mar 16, 2017 at 06:01:35PM +0000, Peter Maydell wrote:
> On 16 March 2017 at 15:23, Peter Maydell <peter.maydell@linaro.org> wrote:
> > (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.)
> 
> ...unfortunately the gcc compile farm mips board (1) is very slow
> and (2) has very little disk space free in /tmp, which means that
> it can't pass "make check" because for instance tests/test-replication
> assumes it can write comparatively large test files to /tmp/...

This should be enough to make it use the local build dir instead:

diff --git a/tests/test-replication.c b/tests/test-replication.c
index fac2da3..2a61a23 100644
--- a/tests/test-replication.c
+++ b/tests/test-replication.c
@@ -19,14 +19,14 @@
 
 /* primary */
 #define P_ID "primary-id"
-static char p_local_disk[] = "/tmp/p_local_disk.XXXXXX";
+static char p_local_disk[] = "p_local_disk.XXXXXX";
 
 /* secondary */
 #define S_ID "secondary-id"
 #define S_LOCAL_DISK_ID "secondary-local-disk-id"
-static char s_local_disk[] = "/tmp/s_local_disk.XXXXXX";
-static char s_active_disk[] = "/tmp/s_active_disk.XXXXXX";
-static char s_hidden_disk[] = "/tmp/s_hidden_disk.XXXXXX";
+static char s_local_disk[] = "s_local_disk.XXXXXX";
+static char s_active_disk[] = "s_active_disk.XXXXXX";
+static char s_hidden_disk[] = "s_hidden_disk.XXXXXX";
 
 /* FIXME: steal from blockdev.c */
 QemuOptsList qemu_drive_opts = {


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/ :|

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Dr. David Alan Gilbert]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On 16 March 2017 at 15:46, Daniel P. Berrange <berrange@redhat.com> wrote:
> > On Thu, Mar 16, 2017 at 03:23:45PM +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
> >>
> >> 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?
> >
> > I think it depends on the level of bit-rot we are aware of, and
> > whether we expect anyone is likely to fix the bit-rot should it
> > be discovered.
> >
> > Simply not having a build machine for QEMU CI doesn't imply that
> > it is totally broken, and even if some pieces are broken, it
> > doesn't imply that QEMU is unusable.
> 
> No, but it does imply that our CI is missing a big chunk.
> Realistically, for the BSDs where I want to get to is "we
> have BSD coverage in our CI setup". The problem at the moment
> is that we (presumably) have BSD users but we have basically
> no BSD developers active upstream, which in my view is not
> a very long-term satisfactory situation.

I build-test the FreeBSD when I do migration pulls; given it's
just a VM it's not too hard; my main reason is that I use it as
a proxy that gives it a good chance to get past your MacOS build.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Markus Armbruster]

"Daniel P. Berrange" <berrange@redhat.com> writes:

> On Thu, Mar 16, 2017 at 03:55:13PM +0000, Peter Maydell wrote:
>> On 16 March 2017 at 15:46, Daniel P. Berrange <berrange@redhat.com> wrote:
>> > On Thu, Mar 16, 2017 at 03:23:45PM +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
>> >>
>> >> 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?
>> >
>> > I think it depends on the level of bit-rot we are aware of, and
>> > whether we expect anyone is likely to fix the bit-rot should it
>> > be discovered.
>> >
>> > Simply not having a build machine for QEMU CI doesn't imply that
>> > it is totally broken, and even if some pieces are broken, it
>> > doesn't imply that QEMU is unusable.
>> 
>> No, but it does imply that our CI is missing a big chunk.
>> Realistically, for the BSDs where I want to get to is "we
>> have BSD coverage in our CI setup". The problem at the moment
>> is that we (presumably) have BSD users but we have basically
>> no BSD developers active upstream, which in my view is not
>> a very long-term satisfactory situation.
>> 
>> > 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.
>
> IMHO we should not be afraid of cleaning up code in such cases.
> If bsd-user accidentally breaks because we clean up some other
> parts of QEMU, so be it. If someone cares they'll step forward,
> if not, it'll be a sign that it its material for tier 3 & thus
> eventual removal.
>
> I'm just pretty wary of gratuitously deleting stuff that still
> has a reasonable chance of being functional, simply because
> we lack CI testing.

That's pre-git thinking :)

I've done a fair amount of cleanup work.  Having to touch something you
can't test *always* deters.  Working CI is the rock-bottom level of "can
test".

Sure, "if somebody cares, they'll step forward" to fix whatever I break.
Eventually.  But I'd like to turn this argument inside out: if somebody
cares, they can bloody well make CI work, so it doesn't break so easily.
If they discover they care only after we dropped support, they can
bloody well fish its code out of git.

I'm willing to tolerate the odd host-specific configure snippet without
CI.  But no conditional compilation, be it via Make or #if.

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Thomas Huth]

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).

... and I think we should add a message to the configure script for 2.9
when somebody tries to use these subsystems, so that the removal does
not happen without warning first?

 Thomas

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 16 March 2017 at 18:59, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
> I build-test the FreeBSD when I do migration pulls; given it's
> just a VM it's not too hard; my main reason is that I use it as
> a proxy that gives it a good chance to get past your MacOS build.

Yeah, I have no in principle objection to using a VM here. It's
just that the last couple of times I've tried it I've messed
around for an hour or so and failed to get a VM setup that
Just Works (ie serial console without graphics window, network
setup that doesn't expose the VM to the external network but still
lets me ssh into it, etc). If we don't have an externally
maintained machine we can use then I think good wiki documentation
on how to set up the VM locally is a minimum.

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Daniel P. Berrange]

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/ :|

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 17 March 2017 at 10:12, Daniel P. Berrange <berrange@redhat.com> wrote:
> 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)

It's because Sean is (on-and-off) still around that I'm not
very inclined to delete bsd-user. We actually have somebody
who cares about the code, which means we should move it into
tier 1, not dump it into tier 3 and delete.

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Thomas Huth]

On 17.03.2017 11:15, Peter Maydell wrote:
> On 17 March 2017 at 10:12, Daniel P. Berrange <berrange@redhat.com> wrote:
>> 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)
> 
> It's because Sean is (on-and-off) still around that I'm not
> very inclined to delete bsd-user. We actually have somebody
> who cares about the code, which means we should move it into
> tier 1, not dump it into tier 3 and delete.

OK, fair, but even Sean was suggesting to purge the old code first ...
so maybe we should just do so and start with a new bsd-user folder when
he is ready?

 Thomas

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 17 March 2017 at 10:30, Thomas Huth <thuth@redhat.com> wrote:
> On 17.03.2017 11:15, Peter Maydell wrote:
>> On 17 March 2017 at 10:12, Daniel P. Berrange <berrange@redhat.com> wrote:
>>> 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)
>>
>> It's because Sean is (on-and-off) still around that I'm not
>> very inclined to delete bsd-user. We actually have somebody
>> who cares about the code, which means we should move it into
>> tier 1, not dump it into tier 3 and delete.
>
> OK, fair, but even Sean was suggesting to purge the old code first ...
> so maybe we should just do so and start with a new bsd-user folder when
> he is ready?

That's not so great for the other BSDs, and I'm not convinced that
"here's a huge pile of code" is going to be easier to review than
the incremental changes.

(It's the "what's easiest to review" part I think is most important.)

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

On 03/16/2017 10:46 AM, Daniel P. Berrange wrote:

> 
>> 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.
> 
> Cygwin is different enough from mingw that I'd basically call
> it a completely separate platform. IOW, successfull mingw
> builds don't offer a strong guarantee of a succesfull cygwin
> build.

I'm late to the thread, but I'll chime in here:
I don't think qemu has ever successfully built on native cygwin.  There
have already been cleanup patches to the list in the meantime to rip out
the (stunted) configure support for using cygwin as the host to do a
cross-compilation to mingw, which as long as it was present meant that
no one could even attempt a native cygwin build (at least not without
jumping through some big hoops).

I have a soft spot for Cygwin (after all, I still maintain several
packages for that platform), but not enough time to even attempt a qemu
build (to see what breaks), nor enough resources to contribute a Cygwin
CI machine to the build-bots, so I have no heartbreak that Cygwin is
(currently) in the list of unsupported platforms.  If someone (maybe me)
ever cares enough to get qemu building on Cygwin, we can always amend
the list of supported platforms at that date.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 16 March 2017 at 15:23, Peter Maydell <peter.maydell@linaro.org> wrote:
>> (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.)
>
> ...unfortunately the gcc compile farm mips board (1) is very slow
> and (2) has very little disk space free in /tmp, which means that
> it can't pass "make check" because for instance tests/test-replication
> assumes it can write comparatively large test files to /tmp/...

That makes it sound like a mips cross build or mips linux-user powered
image would be useful then?

--
Alex Bennée

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 22 March 2017 at 12:51, Alex Bennée <alex.bennee@linaro.org> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>> ...unfortunately the gcc compile farm mips board (1) is very slow
>> and (2) has very little disk space free in /tmp, which means that
>> it can't pass "make check" because for instance tests/test-replication
>> assumes it can write comparatively large test files to /tmp/...
>
> That makes it sound like a mips cross build or mips linux-user powered
> image would be useful then?

Cross build can't actually run 'make check' and I wouldn't
trust linux-user to run our test suite. Also, if there's
no hardware that we can sensibly do make/make check
on then how much can people really care about QEMU on MIPS?
(In fact since MIPS supports KVM these days, there really
ought to be sufficiently capable hardware to work as
a build system.)

The "test uses /tmp/" stuff is a test suite bug which
we should fix, which might make the gcc cfarm box at
least kind of usable.

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Thomas Huth]

On 22.03.2017 14:09, Peter Maydell wrote:
> On 22 March 2017 at 12:51, Alex Bennée <alex.bennee@linaro.org> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>> ...unfortunately the gcc compile farm mips board (1) is very slow
>>> and (2) has very little disk space free in /tmp, which means that
>>> it can't pass "make check" because for instance tests/test-replication
>>> assumes it can write comparatively large test files to /tmp/...
>>
>> That makes it sound like a mips cross build or mips linux-user powered
>> image would be useful then?
> 
> Cross build can't actually run 'make check' and I wouldn't
> trust linux-user to run our test suite. Also, if there's
> no hardware that we can sensibly do make/make check
> on then how much can people really care about QEMU on MIPS?
> (In fact since MIPS supports KVM these days, there really
> ought to be sufficiently capable hardware to work as
> a build system.)

Maybe one of our MIPS maintainers has a clue whether there is a public
MIPS build machine available somewhere? (I've put them on CC:)

 Thomas

[Qemu-devel] rawhide gcc failures [was: Proposal for deprecating unsupported host OSes & architecutures]

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 5598 bytes --]

On 03/16/2017 10:23 AM, 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:

Tangentially-related: do we officially support bleeding-edge OS builds?
For example, current rawhide has a new-enough gcc that gives some
(possibly-useful) new warnings (-Werror=format-truncation) that fire
when formatting what can be easily proven to be larger than a
fixed-width buffer will hold.  If rawhide is not a current target, then
I don't need to spend any time on this (yet); but if rawhide builds ARE
supported, then we want this patched before 2.9:


  CC      block/blkdebug.o
block/blkdebug.c: In function ‘blkdebug_refresh_filename’:
block/blkdebug.c:693:31: error: ‘%s’ directive output may be truncated
writing up to 4095 bytes into a region of size 4086
[-Werror=format-truncation=]
                  "blkdebug:%s:%s", s->config_file ?: "",
                               ^~
block/blkdebug.c:692:9: note: ‘snprintf’ output 11 or more bytes
(assuming 4106) into a destination of size 4096
         snprintf(bs->exact_filename, sizeof(bs->exact_filename),
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  "blkdebug:%s:%s", s->config_file ?: "",
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  bs->file->bs->exact_filename);
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/home/dummy/qemu/rules.mak:69: block/blkdebug.o] Error 1
  CC      block/blkverify.o
block/blkverify.c: In function ‘blkverify_refresh_filename’:
block/blkverify.c:309:29: error: ‘%s’ directive output may be truncated
writing up to 4095 bytes into a region of size 4086
[-Werror=format-truncation=]
                  "blkverify:%s:%s",
                             ^~
block/blkverify.c:308:9: note: ‘snprintf’ output between 12 and 8202
bytes into a destination of size 4096
         snprintf(bs->exact_filename, sizeof(bs->exact_filename),
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  "blkverify:%s:%s",
                  ~~~~~~~~~~~~~~~~~~
                  bs->file->bs->exact_filename,
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  s->test_file->bs->exact_filename);
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/home/dummy/qemu/rules.mak:69: block/blkverify.o] Error 1
  CC      hw/usb/bus.o
hw/usb/bus.c: In function ‘usb_port_location’:
hw/usb/bus.c:410:66: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size between 0 and 15
[-Werror=format-truncation=]
         snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
                                                                  ^~
hw/usb/bus.c:410:9: note: ‘snprintf’ output between 3 and 28 bytes into
a destination of size 16
         snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  upstream->path, portnr);
                  ~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/home/dummy/qemu/rules.mak:69: hw/usb/bus.o] Error 1
  CC      net/slirp.o
net/slirp.c: In function ‘slirp_smb_cleanup’:
net/slirp.c:565:44: error: ‘%s’ directive output may be truncated
writing up to 127 bytes into a region of size 121
[-Werror=format-truncation=]
         snprintf(cmd, sizeof(cmd), "rm -rf %s", s->smb_dir);
                                            ^~
net/slirp.c:565:9: note: ‘snprintf’ output between 8 and 135 bytes into
a destination of size 128
         snprintf(cmd, sizeof(cmd), "rm -rf %s", s->smb_dir);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/slirp.c: In function ‘slirp_smb’:
net/slirp.c:609:46: error: ‘%s’ directive output may be truncated
writing 8 bytes into a region of size between 0 and 127
[-Werror=format-truncation=]
     snprintf(smb_conf, sizeof(smb_conf), "%s/%s", s->smb_dir, "smb.conf");
                                              ^~               ~~~~~~~~~~
net/slirp.c:609:5: note: ‘snprintf’ output between 10 and 137 bytes into
a destination of size 128
     snprintf(smb_conf, sizeof(smb_conf), "%s/%s", s->smb_dir, "smb.conf");
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/slirp.c:654:55: error: ‘%s’ directive output may be truncated
writing up to 127 bytes into a region of size 110
[-Werror=format-truncation=]
     snprintf(smb_cmdline, sizeof(smb_cmdline), "%s -l %s -s %s",
                                                       ^~
net/slirp.c:654:5: note: ‘snprintf’ output 23 or more bytes (assuming
150) into a destination of size 128
     snprintf(smb_cmdline, sizeof(smb_cmdline), "%s -l %s -s %s",
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              CONFIG_SMBD_COMMAND, s->smb_dir, smb_conf);
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/home/dummy/qemu/rules.mak:69: net/slirp.o] Error 1
make: Target 'all' not remade because of errors.


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] rawhide gcc failures [was: Proposal for deprecating unsupported host OSes & architecutures]

[Philippe Mathieu-Daudé]

so lovely...

as a start point for bleeding edge stuff this can go in CI as a 
complement of debian images in tests/docker/... using the official 
fedora:rawhide base image.

On 03/22/2017 04:07 PM, Eric Blake wrote:
> On 03/16/2017 10:23 AM, 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:
>
> Tangentially-related: do we officially support bleeding-edge OS builds?
> For example, current rawhide has a new-enough gcc that gives some
> (possibly-useful) new warnings (-Werror=format-truncation) that fire
> when formatting what can be easily proven to be larger than a
> fixed-width buffer will hold.  If rawhide is not a current target, then
> I don't need to spend any time on this (yet); but if rawhide builds ARE
> supported, then we want this patched before 2.9:
>
>
>   CC      block/blkdebug.o
> block/blkdebug.c: In function ‘blkdebug_refresh_filename’:
> block/blkdebug.c:693:31: error: ‘%s’ directive output may be truncated
> writing up to 4095 bytes into a region of size 4086
> [-Werror=format-truncation=]
>                   "blkdebug:%s:%s", s->config_file ?: "",
>                                ^~
> block/blkdebug.c:692:9: note: ‘snprintf’ output 11 or more bytes
> (assuming 4106) into a destination of size 4096
>          snprintf(bs->exact_filename, sizeof(bs->exact_filename),
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   "blkdebug:%s:%s", s->config_file ?: "",
>                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   bs->file->bs->exact_filename);
>                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [/home/dummy/qemu/rules.mak:69: block/blkdebug.o] Error 1
>   CC      block/blkverify.o
> block/blkverify.c: In function ‘blkverify_refresh_filename’:
> block/blkverify.c:309:29: error: ‘%s’ directive output may be truncated
> writing up to 4095 bytes into a region of size 4086
> [-Werror=format-truncation=]
>                   "blkverify:%s:%s",
>                              ^~
> block/blkverify.c:308:9: note: ‘snprintf’ output between 12 and 8202
> bytes into a destination of size 4096
>          snprintf(bs->exact_filename, sizeof(bs->exact_filename),
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   "blkverify:%s:%s",
>                   ~~~~~~~~~~~~~~~~~~
>                   bs->file->bs->exact_filename,
>                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   s->test_file->bs->exact_filename);
>                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [/home/dummy/qemu/rules.mak:69: block/blkverify.o] Error 1
>   CC      hw/usb/bus.o
> hw/usb/bus.c: In function ‘usb_port_location’:
> hw/usb/bus.c:410:66: error: ‘%d’ directive output may be truncated
> writing between 1 and 11 bytes into a region of size between 0 and 15
> [-Werror=format-truncation=]
>          snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
>                                                                   ^~
> hw/usb/bus.c:410:9: note: ‘snprintf’ output between 3 and 28 bytes into
> a destination of size 16
>          snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                   upstream->path, portnr);
>                   ~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [/home/dummy/qemu/rules.mak:69: hw/usb/bus.o] Error 1
>   CC      net/slirp.o
> net/slirp.c: In function ‘slirp_smb_cleanup’:
> net/slirp.c:565:44: error: ‘%s’ directive output may be truncated
> writing up to 127 bytes into a region of size 121
> [-Werror=format-truncation=]
>          snprintf(cmd, sizeof(cmd), "rm -rf %s", s->smb_dir);
>                                             ^~
> net/slirp.c:565:9: note: ‘snprintf’ output between 8 and 135 bytes into
> a destination of size 128
>          snprintf(cmd, sizeof(cmd), "rm -rf %s", s->smb_dir);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> net/slirp.c: In function ‘slirp_smb’:
> net/slirp.c:609:46: error: ‘%s’ directive output may be truncated
> writing 8 bytes into a region of size between 0 and 127
> [-Werror=format-truncation=]
>      snprintf(smb_conf, sizeof(smb_conf), "%s/%s", s->smb_dir, "smb.conf");
>                                               ^~               ~~~~~~~~~~
> net/slirp.c:609:5: note: ‘snprintf’ output between 10 and 137 bytes into
> a destination of size 128
>      snprintf(smb_conf, sizeof(smb_conf), "%s/%s", s->smb_dir, "smb.conf");
>      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> net/slirp.c:654:55: error: ‘%s’ directive output may be truncated
> writing up to 127 bytes into a region of size 110
> [-Werror=format-truncation=]
>      snprintf(smb_cmdline, sizeof(smb_cmdline), "%s -l %s -s %s",
>                                                        ^~
> net/slirp.c:654:5: note: ‘snprintf’ output 23 or more bytes (assuming
> 150) into a destination of size 128
>      snprintf(smb_cmdline, sizeof(smb_cmdline), "%s -l %s -s %s",
>      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>               CONFIG_SMBD_COMMAND, s->smb_dir, smb_conf);
>               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [/home/dummy/qemu/rules.mak:69: net/slirp.o] Error 1
> make: Target 'all' not remade because of errors.
>
>

Re: [Qemu-devel] rawhide gcc failures [was: Proposal for deprecating unsupported host OSes & architecutures]

[Peter Maydell]

On 22 March 2017 at 19:07, Eric Blake <eblake@redhat.com> wrote:
> Tangentially-related: do we officially support bleeding-edge OS builds?
> For example, current rawhide has a new-enough gcc that gives some
> (possibly-useful) new warnings (-Werror=format-truncation)

Depends what you mean by "support". Are we testing them
in our build/CI loop? Apparently not :-) Do we fix them?
Yep, certainly, because bleeding-edge libraries and
compilers will eventually be standard ones. Do we fix
them during the release process? Yes, but maybe if
the fix is very invasive somehow we might prefer to
postpone to the next release. Do we consider them
a release-critical bug that we'd spin an extra rc
for? I don't think so, because (a) for released tarballs
-Werror is not on by default (b) even for building from
git you can work around this with -disable-werror
(c) it's just an accident of timing if a new gcc drops
3 weeks before release rather than 3 weeks after, so
it's always possible that releases will end up being
built on compilers that warn about things in them.

More generally, I'm not going to go so far as to insist
that we have a build machine for every flavour of every
distro -- that would not usefully improve coverage I think.
Also I'm happy to be ad-hoc about exactly what we test
(my x86 Linux builds are just "the Ubuntu flavour my
desktop box happens to be running right now") because
being less ad-hoc feels like it would be work that
we don't really need to engage in.

thanks
-- PMM

Re: [Qemu-devel] rawhide gcc failures [was: Proposal for deprecating unsupported host OSes & architecutures]

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 22 March 2017 at 19:07, Eric Blake <eblake@redhat.com> wrote:
>> Tangentially-related: do we officially support bleeding-edge OS builds?
>> For example, current rawhide has a new-enough gcc that gives some
>> (possibly-useful) new warnings (-Werror=format-truncation)
>
> Depends what you mean by "support". Are we testing them
> in our build/CI loop? Apparently not :-)

We test some. The Travis loop currently installs the toolchain PPAs for
two of its runs to use:

        - COMPILER_NAME=clang CXX=clang++-3.9 CC=clang-3.9
        - COMPILER_NAME=gcc CXX=g++-5 CC=gcc-5

That said it probably makes more sense to add a rawhide docker image for
testing. Whether it is worth running it on every patch series remains to
be seen as while it might give some advanced warning could it also be
because the bleeding edge distro is broken in some other way?

> Do we fix them?
> Yep, certainly, because bleeding-edge libraries and
> compilers will eventually be standard ones. Do we fix
> them during the release process? Yes, but maybe if
> the fix is very invasive somehow we might prefer to
> postpone to the next release. Do we consider them
> a release-critical bug that we'd spin an extra rc
> for? I don't think so, because (a) for released tarballs
> -Werror is not on by default (b) even for building from
> git you can work around this with -disable-werror
> (c) it's just an accident of timing if a new gcc drops
> 3 weeks before release rather than 3 weeks after, so
> it's always possible that releases will end up being
> built on compilers that warn about things in them.
>
> More generally, I'm not going to go so far as to insist
> that we have a build machine for every flavour of every
> distro -- that would not usefully improve coverage I think.
> Also I'm happy to be ad-hoc about exactly what we test
> (my x86 Linux builds are just "the Ubuntu flavour my
> desktop box happens to be running right now") because
> being less ad-hoc feels like it would be work that
> we don't really need to engage in.
>
> thanks
> -- PMM


--
Alex Bennée

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Paolo Bonzini]

On 22/03/2017 14:09, Peter Maydell wrote:
> On 22 March 2017 at 12:51, Alex Bennée <alex.bennee@linaro.org> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>> ...unfortunately the gcc compile farm mips board (1) is very slow
>>> and (2) has very little disk space free in /tmp, which means that
>>> it can't pass "make check" because for instance tests/test-replication
>>> assumes it can write comparatively large test files to /tmp/...
>>
>> That makes it sound like a mips cross build or mips linux-user powered
>> image would be useful then?
> 
> Cross build can't actually run 'make check' and I wouldn't
> trust linux-user to run our test suite. Also, if there's
> no hardware that we can sensibly do make/make check
> on then how much can people really care about QEMU on MIPS?
> (In fact since MIPS supports KVM these days, there really
> ought to be sufficiently capable hardware to work as
> a build system.)

I own a MIPS Creator ci20 board (donated by Imagination Technologies).
I cannot give it a public IP address, but I can try and use it to do
builds every now and then.

Paolo

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 23 March 2017 at 10:33, Paolo Bonzini <pbonzini@redhat.com> wrote:
> I own a MIPS Creator ci20 board (donated by Imagination Technologies).
> I cannot give it a public IP address, but I can try and use it to do
> builds every now and then.

I think our best bet is probably to fix our test suite's
overreliance on /tmp/. Then the gcc cfarm box will probably do.

I've also had a kind offer of access to a SPARC box, which
I'm following up on.

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Richard Henderson]

On 03/23/2017 09:02 PM, Peter Maydell wrote:
> On 23 March 2017 at 10:33, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> I own a MIPS Creator ci20 board (donated by Imagination Technologies).
>> I cannot give it a public IP address, but I can try and use it to do
>> builds every now and then.
>
> I think our best bet is probably to fix our test suite's
> overreliance on /tmp/. Then the gcc cfarm box will probably do.
>
> I've also had a kind offer of access to a SPARC box, which
> I'm following up on.

I also have access to a sparc box.

(At the moment I'm trying to update it from 2013 era system libraries, and to 
enable the 64-bit userland, before I do any testing of current mainline.)


r~

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 24 March 2017 at 01:28, Richard Henderson <rth@twiddle.net> wrote:
> I also have access to a sparc box.
>
> (At the moment I'm trying to update it from 2013 era system libraries, and
> to enable the 64-bit userland, before I do any testing of current mainline.)

So far I have found that we seem to be mishandling 32-bit guest
load/stores, which I tentatively suggest

diff --git a/tcg/sparc/tcg-target.inc.c b/tcg/sparc/tcg-target.inc.c
index d1f4c0dead..c72b57dc58 100644
--- a/tcg/sparc/tcg-target.inc.c
+++ b/tcg/sparc/tcg-target.inc.c
@@ -1119,7 +1119,7 @@ static void tcg_out_qemu_ld(TCGContext *s,
TCGReg data, TCGReg addr,
         /* Skip the high-part; we'll perform the extract in the trampoline.  */
         param++;
     }
-    tcg_out_mov(s, TCG_TYPE_REG, param++, addr);
+    tcg_out_mov(s, TCG_TYPE_REG, param++, addrz);

     /* We use the helpers to extend SB and SW data, leaving the case
        of SL needing explicit extending below.  */
@@ -1199,7 +1199,7 @@ static void tcg_out_qemu_st(TCGContext *s,
TCGReg data, TCGReg addr,
         /* Skip the high-part; we'll perform the extract in the trampoline.  */
         param++;
     }
-    tcg_out_mov(s, TCG_TYPE_REG, param++, addr);
+    tcg_out_mov(s, TCG_TYPE_REG, param++, addrz);
     if (!SPARC64 && (memop & MO_SIZE) == MO_64) {
         /* Skip the high-part; we'll perform the extract in the trampoline.  */
         param++;

(otherwise we pass a high-bits-set value to the slowpath functions,
which happens to work if QEMU was built with debug enabled but not
if it doesn't.)

That then at least makes i386 and x86_64 guests behave the same,
ie they don't work. I haven't figured out what's going wrong there yet.

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Knut Omang]

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
> 

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 25 March 2017 at 20:49, Knut Omang <knut.omang@oracle.com> wrote:
> Can we please keep the Sparc support in for a while still?

Yes, John Paul Adrian Glaubitz and the Debian Project have
kindly provided me with access to a Sparc box. I'm planning
to send a patch that puts sparc into the 'supported'
category before 2.9 release.

I would note that so far I've found a couple of TCG
bugs of the "this just doesn't work at all" level, so
it doesn't look like anybody using sparc has been
doing any testing against git master...

> 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.

I'd recommend trying to get a machine into the gcc compile
farm (assuming they'd be willing to take it) -- that way
it's accessible to developers for a range of open
source projects.

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Knut Omang]

On Sat, 2017-03-25 at 21:15 +0000, Peter Maydell wrote:
> On 25 March 2017 at 20:49, Knut Omang <knut.omang@oracle.com> wrote:
> > 
> > Can we please keep the Sparc support in for a while still?
> 
> Yes, John Paul Adrian Glaubitz and the Debian Project have
> kindly provided me with access to a Sparc box. I'm planning
> to send a patch that puts sparc into the 'supported'
> category before 2.9 release.

good to hear!

> I would note that so far I've found a couple of TCG
> bugs of the "this just doesn't work at all" level, so
> it doesn't look like anybody using sparc has been
> doing any testing against git master...

No, I tried a while ago myself without much success so there's awareness
about this sad state. Hopefully we can get some momentum on it soon.

> > 
> > 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.
> 
> I'd recommend trying to get a machine into the gcc compile
> farm (assuming they'd be willing to take it) -- that way
> it's accessible to developers for a range of open
> source projects.

I'll bring that suggestion forward,

Thanks,
Knut

> 
> thanks
> -- PMM

Re: [Qemu-devel] rawhide gcc failures [was: Proposal for deprecating unsupported host OSes & architecutures]

[Fam Zheng]

On Wed, 03/22 16:39, Philippe Mathieu-Daudé wrote:
> so lovely...
> 
> as a start point for bleeding edge stuff this can go in CI as a complement
> of debian images in tests/docker/... using the official fedora:rawhide base
> image.

That is an interesting question. Current patchew tester setup never updates the
docker image which means fedora:latest or fedora:rawhide won't get "refreshed"
at each test run, over time they get out-of-date. We should have a way to
periodically update it..

I can also work on a patch to add fedora:rawhide to tests/docker, but I'm not
100% sure that we want to add it to the first class test combinations - there
could be noise if something regresses in rawhide.

Still, we can make one move a time.  Thanks,

Fam

> 
> On 03/22/2017 04:07 PM, Eric Blake wrote:
> > On 03/16/2017 10:23 AM, 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:
> > 
> > Tangentially-related: do we officially support bleeding-edge OS builds?
> > For example, current rawhide has a new-enough gcc that gives some
> > (possibly-useful) new warnings (-Werror=format-truncation) that fire
> > when formatting what can be easily proven to be larger than a
> > fixed-width buffer will hold.  If rawhide is not a current target, then
> > I don't need to spend any time on this (yet); but if rawhide builds ARE
> > supported, then we want this patched before 2.9:
> > 
> > 
> >   CC      block/blkdebug.o
> > block/blkdebug.c: In function ‘blkdebug_refresh_filename’:
> > block/blkdebug.c:693:31: error: ‘%s’ directive output may be truncated
> > writing up to 4095 bytes into a region of size 4086
> > [-Werror=format-truncation=]
> >                   "blkdebug:%s:%s", s->config_file ?: "",
> >                                ^~
> > block/blkdebug.c:692:9: note: ‘snprintf’ output 11 or more bytes
> > (assuming 4106) into a destination of size 4096
> >          snprintf(bs->exact_filename, sizeof(bs->exact_filename),
> >          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >                   "blkdebug:%s:%s", s->config_file ?: "",
> >                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >                   bs->file->bs->exact_filename);
> >                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> > make: *** [/home/dummy/qemu/rules.mak:69: block/blkdebug.o] Error 1
> >   CC      block/blkverify.o
> > block/blkverify.c: In function ‘blkverify_refresh_filename’:
> > block/blkverify.c:309:29: error: ‘%s’ directive output may be truncated
> > writing up to 4095 bytes into a region of size 4086
> > [-Werror=format-truncation=]
> >                   "blkverify:%s:%s",
> >                              ^~
> > block/blkverify.c:308:9: note: ‘snprintf’ output between 12 and 8202
> > bytes into a destination of size 4096
> >          snprintf(bs->exact_filename, sizeof(bs->exact_filename),
> >          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >                   "blkverify:%s:%s",
> >                   ~~~~~~~~~~~~~~~~~~
> >                   bs->file->bs->exact_filename,
> >                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >                   s->test_file->bs->exact_filename);
> >                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> > make: *** [/home/dummy/qemu/rules.mak:69: block/blkverify.o] Error 1
> >   CC      hw/usb/bus.o
> > hw/usb/bus.c: In function ‘usb_port_location’:
> > hw/usb/bus.c:410:66: error: ‘%d’ directive output may be truncated
> > writing between 1 and 11 bytes into a region of size between 0 and 15
> > [-Werror=format-truncation=]
> >          snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
> >                                                                   ^~
> > hw/usb/bus.c:410:9: note: ‘snprintf’ output between 3 and 28 bytes into
> > a destination of size 16
> >          snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
> >          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >                   upstream->path, portnr);
> >                   ~~~~~~~~~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> > make: *** [/home/dummy/qemu/rules.mak:69: hw/usb/bus.o] Error 1
> >   CC      net/slirp.o
> > net/slirp.c: In function ‘slirp_smb_cleanup’:
> > net/slirp.c:565:44: error: ‘%s’ directive output may be truncated
> > writing up to 127 bytes into a region of size 121
> > [-Werror=format-truncation=]
> >          snprintf(cmd, sizeof(cmd), "rm -rf %s", s->smb_dir);
> >                                             ^~
> > net/slirp.c:565:9: note: ‘snprintf’ output between 8 and 135 bytes into
> > a destination of size 128
> >          snprintf(cmd, sizeof(cmd), "rm -rf %s", s->smb_dir);
> >          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > net/slirp.c: In function ‘slirp_smb’:
> > net/slirp.c:609:46: error: ‘%s’ directive output may be truncated
> > writing 8 bytes into a region of size between 0 and 127
> > [-Werror=format-truncation=]
> >      snprintf(smb_conf, sizeof(smb_conf), "%s/%s", s->smb_dir, "smb.conf");
> >                                               ^~               ~~~~~~~~~~
> > net/slirp.c:609:5: note: ‘snprintf’ output between 10 and 137 bytes into
> > a destination of size 128
> >      snprintf(smb_conf, sizeof(smb_conf), "%s/%s", s->smb_dir, "smb.conf");
> >      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > net/slirp.c:654:55: error: ‘%s’ directive output may be truncated
> > writing up to 127 bytes into a region of size 110
> > [-Werror=format-truncation=]
> >      snprintf(smb_cmdline, sizeof(smb_cmdline), "%s -l %s -s %s",
> >                                                        ^~
> > net/slirp.c:654:5: note: ‘snprintf’ output 23 or more bytes (assuming
> > 150) into a destination of size 128
> >      snprintf(smb_cmdline, sizeof(smb_cmdline), "%s -l %s -s %s",
> >      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >               CONFIG_SMBD_COMMAND, s->smb_dir, smb_conf);
> >               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> > make: *** [/home/dummy/qemu/rules.mak:69: net/slirp.o] Error 1
> > make: Target 'all' not remade because of errors.
> > 
> > 

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Peter Maydell]

On 26 March 2017 at 10:16, Knut Omang <knut.omang@oracle.com> wrote:
> On Sat, 2017-03-25 at 21:15 +0000, Peter Maydell wrote:
>> On 25 March 2017 at 20:49, Knut Omang <knut.omang@oracle.com> wrote:
>> >
>> > Can we please keep the Sparc support in for a while still?
>>
>> Yes, John Paul Adrian Glaubitz and the Debian Project have
>> kindly provided me with access to a Sparc box. I'm planning
>> to send a patch that puts sparc into the 'supported'
>> category before 2.9 release.
>
> good to hear!

It occurred to me that it might be helpful to point out that
support of Solaris as a host OS is a separate thing and is
still in the 'unsupported' category. (It's also quite high
on the list of stuff to drop because I suspect it's broken
and it's one of the things making a mess of our configure code.)

thanks
-- PMM

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Knut Omang]

On Mon, 2017-03-27 at 17:32 +0100, Peter Maydell wrote:
> On 26 March 2017 at 10:16, Knut Omang <knut.omang@oracle.com> wrote:
> > On Sat, 2017-03-25 at 21:15 +0000, Peter Maydell wrote:
> >> On 25 March 2017 at 20:49, Knut Omang <knut.omang@oracle.com> wrote:
> >> >
> >> > Can we please keep the Sparc support in for a while still?
> >>
> >> Yes, John Paul Adrian Glaubitz and the Debian Project have
> >> kindly provided me with access to a Sparc box. I'm planning
> >> to send a patch that puts sparc into the 'supported'
> >> category before 2.9 release.
> >
> > good to hear!
> 
> It occurred to me that it might be helpful to point out that
> support of Solaris as a host OS is a separate thing and is
> still in the 'unsupported' category. 

Yes, that's my understanding too, but thanks for highlighting it.

> (It's also quite high
> on the list of stuff to drop because I suspect it's broken
> and it's one of the things making a mess of our configure code.)

I agree, and from what I have been able to figure out, 
it seems there are no imminent problems with removing it,

Thanks,
Knut

> 
> thanks
> -- PMM