configure | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 2 deletions(-)
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(-)
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
--
2.7.4
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/ :|
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
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/ :|
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
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
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
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
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
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~
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
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
© 2016 - 2024 Red Hat, Inc.