configure: Warn about deprecated hosts

Message ID 1489748902-21765-1-git-send-email-peter.maydell@linaro.org
State Superseded
Headers show

Commit Message

Peter Maydell March 17, 2017, 11:08 a.m.
We plan to drop support in a future QEMU release for host OSes
and host architectures for which we have no test machine where
we can build and run tests. For the 2.9 release, make configure
print a warning if it is run on such a host, so that the user
has some warning of the plans and can volunteer to help us
maintain the port if they need it to continue to function.

This commit flags up as deprecated the CPU architectures:
 * ia64
 * sparc
 * anything which we don't have a TCG port for
   (and which was presumably using TCI)
and the OSes:
 * Cygwin
 * GNU/kFreeBSD
 * FreeBSD
 * DragonFly BSD
 * NetBSD
 * OpenBSD
 * Solaris
 * AIX
 * Haiku

It also makes entirely unrecognized host OS strings be
rejected rather than treated as if they were Linux (which
likely never worked).

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

---
This list is definitely too all-encompassing, and we should
move at least some of the BSDs into "not-deprecated".
I'm posting the patch for the moment for code review on the
logic and as a placeholder.
---
 configure | 48 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 46 insertions(+), 2 deletions(-)

-- 
2.7.4

Comments

Daniel P. Berrange March 17, 2017, 11:49 a.m. | #1
On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote:
> We plan to drop support in a future QEMU release for host OSes

> and host architectures for which we have no test machine where

> we can build and run tests. For the 2.9 release, make configure

> print a warning if it is run on such a host, so that the user

> has some warning of the plans and can volunteer to help us

> maintain the port if they need it to continue to function.

> 

> This commit flags up as deprecated the CPU architectures:

>  * ia64

>  * sparc

>  * anything which we don't have a TCG port for

>    (and which was presumably using TCI)


This seems to imply that if we remove supported for these architectures,
then TCI is no longer required either, or would there be other reasons
to want to keep TCI around, even when all host archs have a TCG port ? 

> and the OSes:

>  * Cygwin

>  * GNU/kFreeBSD

>  * FreeBSD

>  * DragonFly BSD

>  * NetBSD

>  * OpenBSD

>  * Solaris

>  * AIX

>  * Haiku

> 

> It also makes entirely unrecognized host OS strings be

> rejected rather than treated as if they were Linux (which

> likely never worked).

> 

> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

> ---

> This list is definitely too all-encompassing, and we should

> move at least some of the BSDs into "not-deprecated".

> I'm posting the patch for the moment for code review on the

> logic and as a placeholder.


FreeBSD is the one where I most frequently see developers engaging across
the overall virt tools stack (QEMU/libvirt/virt-manager/OpenStack).
GNU/kFreeBSD has come up a few times in libvirt, and I don't recall seeing
anyone mentioning the remaining BSDs - though perhaps thats because the
FreeBSD port fixes are enough to also make other BSDs work.

> diff --git a/configure b/configure

> index 75c7c35..5ddc985 100755

> --- a/configure

> +++ b/configure

> @@ -321,6 +321,9 @@ tcmalloc="no"

>  jemalloc="no"

>  replication="yes"

>  

> +supported_cpu="no"

> +supported_os="no"

> +

>  # parse CC options first

>  for opt do

>    optarg=$(expr "x$opt" : 'x[^=]*=\(.*\)')

> @@ -517,23 +520,32 @@ ARCH=

>  # Normalise host CPU name and set ARCH.

>  # Note that this case should only have supported host CPUs, not guests.

>  case "$cpu" in

> -  ia64|ppc|ppc64|s390|s390x|sparc64|x32)

> +  ppc|ppc64|s390|s390x|x32)

> +    cpu="$cpu"

> +    supported_cpu="yes"

> +  ;;

> +  ia64|sparc64)

>      cpu="$cpu"

>    ;;

>    i386|i486|i586|i686|i86pc|BePC)

>      cpu="i386"

> +    supported_cpu="yes"

>    ;;

>    x86_64|amd64)

>      cpu="x86_64"

> +    supported_cpu="yes"

>    ;;

>    armv*b|armv*l|arm)

>      cpu="arm"

> +    supported_cpu="yes"

>    ;;

>    aarch64)

>      cpu="aarch64"

> +    supported_cpu="yes"

>    ;;

>    mips*)

>      cpu="mips"

> +    supported_cpu="yes"

>    ;;

>    sparc|sun4[cdmuv])

>      cpu="sparc"

> @@ -568,6 +580,7 @@ MINGW32*)

>    else

>      audio_drv_list=""

>    fi

> +  supported_os="yes"

>  ;;

>  GNU/kFreeBSD)

>    bsd="yes"

> @@ -626,6 +639,7 @@ Darwin)

>    # won't work when we're compiling with gcc as a C compiler.

>    QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS"

>    HOST_VARIANT_DIR="darwin"

> +  supported_os="yes"

>  ;;

>  SunOS)

>    solaris="yes"

> @@ -672,7 +686,7 @@ Haiku)

>    QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS $QEMU_CFLAGS"

>    LIBS="-lposix_error_mapper -lnetwork $LIBS"

>  ;;

> -*)

> +Linux)

>    audio_drv_list="oss"

>    audio_possible_drivers="oss alsa sdl pa"

>    linux="yes"

> @@ -682,6 +696,10 @@ Haiku)

>    vhost_scsi="yes"

>    vhost_vsock="yes"

>    QEMU_INCLUDES="-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers $QEMU_INCLUDES"

> +  supported_os="yes"

> +;;

> +*)

> +  error_exit "Unsupported host OS $targetos"

>  ;;

>  esac

>  

> @@ -5095,6 +5113,32 @@ if test "$sdl_too_old" = "yes"; then

>  echo "-> Your SDL version is too old - please upgrade to have SDL support"

>  fi

>  

> +if test "$supported_cpu" = "no"; then

> +    echo

> +    echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE RELEASES!"

> +    echo

> +    echo "CPU host architecture $cpu support is not currently maintained."

> +    echo "The QEMU project intends to remove support for this host CPU in"

> +    echo "a future release if nobody volunteers to maintain it and to"

> +    echo "provide a build host for our continuous integration setup."

> +    echo "configure has succeeded and you can continue to build, but"

> +    echo "if you care about QEMU on this platform you should contact"

> +    echo "us upstream at qemu-devel@nongnu.org."

> +fi

> +

> +if test "$supported_os" = "no"; then

> +    echo

> +    echo "WARNING: SUPPORT FOR THIS HOST OS WILL GO AWAY IN FUTURE RELEASES!"

> +    echo

> +    echo "CPU host OS $targetos support is not currently maintained."

> +    echo "The QEMU project intends to remove support for this host CPU in"

> +    echo "a future release if nobody volunteers to maintain it and to"

> +    echo "provide a build host for our continuous integration setup."

> +    echo "configure has succeeded and you can continue to build, but"

> +    echo "if you care about QEMU on this platform you should contact"

> +    echo "us upstream at qemu-devel@nongnu.org."

> +fi

> +

>  config_host_mak="config-host.mak"

>  

>  echo "# Automatically generated by configure - do not modify" >config-all-disas.mak


The approach here all looks sane.

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/ :|
Peter Maydell March 17, 2017, 11:52 a.m. | #2
On 17 March 2017 at 11:49, Daniel P. Berrange <berrange@redhat.com> wrote:
> On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote:

>> We plan to drop support in a future QEMU release for host OSes

>> and host architectures for which we have no test machine where

>> we can build and run tests. For the 2.9 release, make configure

>> print a warning if it is run on such a host, so that the user

>> has some warning of the plans and can volunteer to help us

>> maintain the port if they need it to continue to function.

>>

>> This commit flags up as deprecated the CPU architectures:

>>  * ia64

>>  * sparc

>>  * anything which we don't have a TCG port for

>>    (and which was presumably using TCI)

>

> This seems to imply that if we remove supported for these architectures,

> then TCI is no longer required either, or would there be other reasons

> to want to keep TCI around, even when all host archs have a TCG port ?


I've never really seen the point in TCI, but others do, which
is why it's in the tree.

>> This list is definitely too all-encompassing, and we should

>> move at least some of the BSDs into "not-deprecated".

>> I'm posting the patch for the moment for code review on the

>> logic and as a placeholder.

>

> FreeBSD is the one where I most frequently see developers engaging across

> the overall virt tools stack (QEMU/libvirt/virt-manager/OpenStack).

> GNU/kFreeBSD has come up a few times in libvirt, and I don't recall seeing

> anyone mentioning the remaining BSDs - though perhaps thats because the

> FreeBSD port fixes are enough to also make other BSDs work.


Yeah. I'm just struggling with setting up a FreeBSD VM so we
can compile test that. Interesting that GNU/kFreeBSD has users.

thanks
-- PMM
Daniel P. Berrange March 17, 2017, 11:56 a.m. | #3
On Fri, Mar 17, 2017 at 11:52:01AM +0000, Peter Maydell wrote:
> On 17 March 2017 at 11:49, Daniel P. Berrange <berrange@redhat.com> wrote:

> > On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote:

> >> We plan to drop support in a future QEMU release for host OSes

> >> and host architectures for which we have no test machine where

> >> we can build and run tests. For the 2.9 release, make configure

> >> print a warning if it is run on such a host, so that the user

> >> has some warning of the plans and can volunteer to help us

> >> maintain the port if they need it to continue to function.

> >>

> >> This commit flags up as deprecated the CPU architectures:

> >>  * ia64

> >>  * sparc

> >>  * anything which we don't have a TCG port for

> >>    (and which was presumably using TCI)

> >

> > This seems to imply that if we remove supported for these architectures,

> > then TCI is no longer required either, or would there be other reasons

> > to want to keep TCI around, even when all host archs have a TCG port ?

> 

> I've never really seen the point in TCI, but others do, which

> is why it's in the tree.

> 

> >> This list is definitely too all-encompassing, and we should

> >> move at least some of the BSDs into "not-deprecated".

> >> I'm posting the patch for the moment for code review on the

> >> logic and as a placeholder.

> >

> > FreeBSD is the one where I most frequently see developers engaging across

> > the overall virt tools stack (QEMU/libvirt/virt-manager/OpenStack).

> > GNU/kFreeBSD has come up a few times in libvirt, and I don't recall seeing

> > anyone mentioning the remaining BSDs - though perhaps thats because the

> > FreeBSD port fixes are enough to also make other BSDs work.

> 

> Yeah. I'm just struggling with setting up a FreeBSD VM so we

> can compile test that. Interesting that GNU/kFreeBSD has users.


I wouldn't go so far as to say GNU/kFreeBSD has users. It had a few people
who have noticed bits of libvirt didn't compile at times, but I'm not sure
if they actually used the result, or were just building libvirt for sake of
having full platform coverage in Debian packages.

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/ :|
Andrew Jones March 17, 2017, 12:38 p.m. | #4
On Fri, Mar 17, 2017 at 11:49:53AM +0000, Daniel P. Berrange wrote:
> On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote:

> > This list is definitely too all-encompassing, and we should

> > move at least some of the BSDs into "not-deprecated".

> > I'm posting the patch for the moment for code review on the

> > logic and as a placeholder.

> 

> FreeBSD is the one where I most frequently see developers engaging across

> the overall virt tools stack (QEMU/libvirt/virt-manager/OpenStack).

> GNU/kFreeBSD has come up a few times in libvirt, and I don't recall seeing

> anyone mentioning the remaining BSDs - though perhaps thats because the

> FreeBSD port fixes are enough to also make other BSDs work.


OpenBSD just came up this week regarding kvm-unit-tests. Someone is
attempting to test vmd, the openbsd hypervisor, using the openbsd port
of qemu and kvm-unit-tests.

(just pointing that out, not making a deprecate/don't-deprecate statement)

Thanks,
drew
Andrea Bolognani March 17, 2017, 1:10 p.m. | #5
On Fri, 2017-03-17 at 11:56 +0000, Daniel P. Berrange wrote:
> > Yeah. I'm just struggling with setting up a FreeBSD VM so we

> > can compile test that. Interesting that GNU/kFreeBSD has users.


> I wouldn't go so far as to say GNU/kFreeBSD has users. It had a few people

> who have noticed bits of libvirt didn't compile at times, but I'm not sure

> if they actually used the result, or were just building libvirt for sake of

> having full platform coverage in Debian packages.


GNU/kFreeBSD is no longer a release architecture as of
Debian 8.

-- 
Andrea Bolognani / Red Hat / Virtualization
Thomas Huth March 17, 2017, 1:19 p.m. | #6
On 17.03.2017 12:52, Peter Maydell wrote:
> On 17 March 2017 at 11:49, Daniel P. Berrange <berrange@redhat.com> wrote:

>> On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote:

>>> We plan to drop support in a future QEMU release for host OSes

>>> and host architectures for which we have no test machine where

>>> we can build and run tests. For the 2.9 release, make configure

>>> print a warning if it is run on such a host, so that the user

>>> has some warning of the plans and can volunteer to help us

>>> maintain the port if they need it to continue to function.


I like your patch! ... but instead of completely aborting with
"Unsupported host OS" when an unexpected host operating system has been
detected, I'd maybe only print a warning and continue the configure
process - in case it is a POSIX-compatible system, there is at least a
small chance that QEMU can be compiled there.

>>> This commit flags up as deprecated the CPU architectures:

>>>  * ia64

>>>  * sparc

>>>  * anything which we don't have a TCG port for

>>>    (and which was presumably using TCI)

>>

>> This seems to imply that if we remove supported for these architectures,

>> then TCI is no longer required either, or would there be other reasons

>> to want to keep TCI around, even when all host archs have a TCG port ?

> 

> I've never really seen the point in TCI, but others do, which

> is why it's in the tree.


TCI is sometimes useful when debugging problems with TCG backends - you
then have something else to compare the behavior with. I think it might
also be useful when porting QEMU to new architectures.

So could you maybe change your patch that it does not warn when the user
has run configure with the "--enable-tcg-interpreter" option?

>>> This list is definitely too all-encompassing, and we should

>>> move at least some of the BSDs into "not-deprecated".


Right, I just had a look at the changelog, and people contributed at
least patches for FreeBSD and OpenBSD last year, so I'd move at least
those two to the "not-deprecated" list (and I guess at least the other
BSDs are also close enough to these two to be kept).

 Thomas
Peter Maydell March 17, 2017, 1:22 p.m. | #7
On 17 March 2017 at 13:19, Thomas Huth <thuth@redhat.com> wrote:
> On 17.03.2017 12:52, Peter Maydell wrote:

>> On 17 March 2017 at 11:49, Daniel P. Berrange <berrange@redhat.com> wrote:

>>> On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote:

>>>> We plan to drop support in a future QEMU release for host OSes

>>>> and host architectures for which we have no test machine where

>>>> we can build and run tests. For the 2.9 release, make configure

>>>> print a warning if it is run on such a host, so that the user

>>>> has some warning of the plans and can volunteer to help us

>>>> maintain the port if they need it to continue to function.

>

> I like your patch! ... but instead of completely aborting with

> "Unsupported host OS" when an unexpected host operating system has been

> detected, I'd maybe only print a warning and continue the configure

> process - in case it is a POSIX-compatible system, there is at least a

> small chance that QEMU can be compiled there.


That code path tries to enable all the Linux specific stuff
(including KVM and linux-user and so on) and puts linux-headers/
on the include path. It seems very unlikely that it will actually
work even if in theory a generic-POSIX OS might be able to build
QEMU somehow.

This kind of tiny-corner-case stuff is exactly why I want
to drop any attempt to build on an OS or architecture we don't
actually know about. The 99.9% probability is that no user of
QEMU has successfully gone down that code path in configure for
anything that isn't Linux; and yet here we are arguing about what
its behaviour should be.

thanks
-- PMM
Peter Maydell March 17, 2017, 1:25 p.m. | #8
On 17 March 2017 at 13:19, Thomas Huth <thuth@redhat.com> wrote:
> So could you maybe change your patch that it does not warn when the user

> has run configure with the "--enable-tcg-interpreter" option?


Nope. I specifically don't want to enable support for TCI on random
who-knows-what-this-is architectures. It eats up too much time
causing people to worry about "what if this is some weird thing"
when they're trying to refactor code, when in practice nobody
is really using QEMU on oddball host CPUs.

If somebody wants to support QEMU as a TCI-only setup on a
new host architecture, they can submit a patch to configure
that specifically recognizes the host architecture (even
if we don't have a tcg backend for it).

thanks
-- PMM
Thomas Huth March 17, 2017, 1:50 p.m. | #9
On 17.03.2017 14:22, Peter Maydell wrote:
> On 17 March 2017 at 13:19, Thomas Huth <thuth@redhat.com> wrote:

>> On 17.03.2017 12:52, Peter Maydell wrote:

>>> On 17 March 2017 at 11:49, Daniel P. Berrange <berrange@redhat.com> wrote:

>>>> On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote:

>>>>> We plan to drop support in a future QEMU release for host OSes

>>>>> and host architectures for which we have no test machine where

>>>>> we can build and run tests. For the 2.9 release, make configure

>>>>> print a warning if it is run on such a host, so that the user

>>>>> has some warning of the plans and can volunteer to help us

>>>>> maintain the port if they need it to continue to function.

>>

>> I like your patch! ... but instead of completely aborting with

>> "Unsupported host OS" when an unexpected host operating system has been

>> detected, I'd maybe only print a warning and continue the configure

>> process - in case it is a POSIX-compatible system, there is at least a

>> small chance that QEMU can be compiled there.

> 

> That code path tries to enable all the Linux specific stuff

> (including KVM and linux-user and so on) and puts linux-headers/

> on the include path. It seems very unlikely that it will actually

> work even if in theory a generic-POSIX OS might be able to build

> QEMU somehow.


Ah, sorry, you got me slightly wrong. I think it is a good idea that you
replaced the "*)" with "Linux)" in your patch. I rather meant to simply
do "echo" instead of "error_exit" in the new "*)" case.

I now just tried to build QEMU with such a "fake" generic POSIX system
(by hacking configure to not recognize "Linux"), and seems like QEMU
properly compiles in that case - but linking fails because net/tap.c is
missing a tap backend.

So you're right, currently it is not possible to build QEMU on unknown
host systems, i.e. the "error_exit" is indeed justified there (though I
think it would be maybe be possible to also add stubs for missing tap
functions to make it work).

 Thomas
Peter Maydell March 17, 2017, 3:19 p.m. | #10
On 17 March 2017 at 11:08, Peter Maydell <peter.maydell@linaro.org> wrote:
> This commit flags up as deprecated the CPU architectures:

>  * ia64

>  * sparc

>  * anything which we don't have a TCG port for

>    (and which was presumably using TCI)

> and the OSes:

>  * Cygwin

>  * GNU/kFreeBSD

>  * FreeBSD

>  * DragonFly BSD

>  * NetBSD

>  * OpenBSD

>  * Solaris

>  * AIX

>  * Haiku


> This list is definitely too all-encompassing, and we should

> move at least some of the BSDs into "not-deprecated".

> I'm posting the patch for the moment for code review on the

> logic and as a placeholder.

> --


Based on my experiences this afternoon trying to get VMs set
up and build QEMU in them plus feedback in this thread, I'm
going to suggest that:
 * we move FreeBSD to the "supported" list (since we have Sean
   around and I got a VM to build stuff without too much pain;
   bsd-user is currently not compiling though)
 * we leave all the others "unsupported"

In particular, I couldn't get a NetBSD installer to even
boot on KVM, so I have no test setup there. I did get OpenBSD
running but it has several compilation failure problems
(use of non-existent EPROTO, the si.si_band" use in oslib-posix.c
doesn't compile, etc) and the dev environment is totally
unusable in any case.

thanks
-- PMM
Richard Henderson March 17, 2017, 11:15 p.m. | #11
On 03/17/2017 09:52 PM, Peter Maydell wrote:
> On 17 March 2017 at 11:49, Daniel P. Berrange <berrange@redhat.com> wrote:

>> On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote:

>>> We plan to drop support in a future QEMU release for host OSes

>>> and host architectures for which we have no test machine where

>>> we can build and run tests. For the 2.9 release, make configure

>>> print a warning if it is run on such a host, so that the user

>>> has some warning of the plans and can volunteer to help us

>>> maintain the port if they need it to continue to function.

>>>

>>> This commit flags up as deprecated the CPU architectures:

>>>  * ia64

>>>  * sparc

>>>  * anything which we don't have a TCG port for

>>>    (and which was presumably using TCI)

>>

>> This seems to imply that if we remove supported for these architectures,

>> then TCI is no longer required either, or would there be other reasons

>> to want to keep TCI around, even when all host archs have a TCG port ?

>

> I've never really seen the point in TCI, but others do, which

> is why it's in the tree.


I don't see the point in TCI, because it's known to not work for any host that 
has non-trivial calling conventions.

You may recall I once did a re-write that did use libffi to overcome that 
problem.  However, you rightly pointed out at the time that it's just as easy 
to write a proper host backend if one actually cares.


r~

Patch hide | download patch | download mbox

diff --git a/configure b/configure
index 75c7c35..5ddc985 100755
--- a/configure
+++ b/configure
@@ -321,6 +321,9 @@  tcmalloc="no"
 jemalloc="no"
 replication="yes"
 
+supported_cpu="no"
+supported_os="no"
+
 # parse CC options first
 for opt do
   optarg=$(expr "x$opt" : 'x[^=]*=\(.*\)')
@@ -517,23 +520,32 @@  ARCH=
 # Normalise host CPU name and set ARCH.
 # Note that this case should only have supported host CPUs, not guests.
 case "$cpu" in
-  ia64|ppc|ppc64|s390|s390x|sparc64|x32)
+  ppc|ppc64|s390|s390x|x32)
+    cpu="$cpu"
+    supported_cpu="yes"
+  ;;
+  ia64|sparc64)
     cpu="$cpu"
   ;;
   i386|i486|i586|i686|i86pc|BePC)
     cpu="i386"
+    supported_cpu="yes"
   ;;
   x86_64|amd64)
     cpu="x86_64"
+    supported_cpu="yes"
   ;;
   armv*b|armv*l|arm)
     cpu="arm"
+    supported_cpu="yes"
   ;;
   aarch64)
     cpu="aarch64"
+    supported_cpu="yes"
   ;;
   mips*)
     cpu="mips"
+    supported_cpu="yes"
   ;;
   sparc|sun4[cdmuv])
     cpu="sparc"
@@ -568,6 +580,7 @@  MINGW32*)
   else
     audio_drv_list=""
   fi
+  supported_os="yes"
 ;;
 GNU/kFreeBSD)
   bsd="yes"
@@ -626,6 +639,7 @@  Darwin)
   # won't work when we're compiling with gcc as a C compiler.
   QEMU_CFLAGS="-DOS_OBJECT_USE_OBJC=0 $QEMU_CFLAGS"
   HOST_VARIANT_DIR="darwin"
+  supported_os="yes"
 ;;
 SunOS)
   solaris="yes"
@@ -672,7 +686,7 @@  Haiku)
   QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS $QEMU_CFLAGS"
   LIBS="-lposix_error_mapper -lnetwork $LIBS"
 ;;
-*)
+Linux)
   audio_drv_list="oss"
   audio_possible_drivers="oss alsa sdl pa"
   linux="yes"
@@ -682,6 +696,10 @@  Haiku)
   vhost_scsi="yes"
   vhost_vsock="yes"
   QEMU_INCLUDES="-I\$(SRC_PATH)/linux-headers -I$(pwd)/linux-headers $QEMU_INCLUDES"
+  supported_os="yes"
+;;
+*)
+  error_exit "Unsupported host OS $targetos"
 ;;
 esac
 
@@ -5095,6 +5113,32 @@  if test "$sdl_too_old" = "yes"; then
 echo "-> Your SDL version is too old - please upgrade to have SDL support"
 fi
 
+if test "$supported_cpu" = "no"; then
+    echo
+    echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE RELEASES!"
+    echo
+    echo "CPU host architecture $cpu support is not currently maintained."
+    echo "The QEMU project intends to remove support for this host CPU in"
+    echo "a future release if nobody volunteers to maintain it and to"
+    echo "provide a build host for our continuous integration setup."
+    echo "configure has succeeded and you can continue to build, but"
+    echo "if you care about QEMU on this platform you should contact"
+    echo "us upstream at qemu-devel@nongnu.org."
+fi
+
+if test "$supported_os" = "no"; then
+    echo
+    echo "WARNING: SUPPORT FOR THIS HOST OS WILL GO AWAY IN FUTURE RELEASES!"
+    echo
+    echo "CPU host OS $targetos support is not currently maintained."
+    echo "The QEMU project intends to remove support for this host CPU in"
+    echo "a future release if nobody volunteers to maintain it and to"
+    echo "provide a build host for our continuous integration setup."
+    echo "configure has succeeded and you can continue to build, but"
+    echo "if you care about QEMU on this platform you should contact"
+    echo "us upstream at qemu-devel@nongnu.org."
+fi
+
 config_host_mak="config-host.mak"
 
 echo "# Automatically generated by configure - do not modify" >config-all-disas.mak