From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Huth Subject: Obsolete QEMU host environments (was: Re: KVM call for 2017-03-14) Date: Tue, 14 Mar 2017 17:54:43 +0100 Message-ID: References: <87tw6y8bs8.fsf@secure.mitica> <20170314081312.GB13140@stefanha-x1.localdomain> <87wpbstesf.fsf@secure.mitica> <20170314160113.GM2445@work-vm> <20170314162020.GT2652@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Juan Quintela , Peter Maydell , QEMU Developer , KVM devel mailing list , Stefan Hajnoczi , Richard Henderson , Aurelien Jarno To: "Daniel P. Berrange" , "Dr. David Alan Gilbert" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58264 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750984AbdCNQyz (ORCPT ); Tue, 14 Mar 2017 12:54:55 -0400 In-Reply-To: <20170314162020.GT2652@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 14.03.2017 17:20, Daniel P. Berrange wrote: > On Tue, Mar 14, 2017 at 04:01:14PM +0000, Dr. David Alan Gilbert wrote: >> * Juan Quintela (quintela@redhat.com) wrote: >>> Peter Maydell wrote: >>>> On 14 March 2017 at 09:13, Stefan Hajnoczi wrote: >>>>> On Mon, Mar 13, 2017 at 11:02:01AM +0100, Peter Maydell wrote: >>>>> The minimum requirements for the new language: >>>>> 1. Does it support the host operating systems that QEMU runs on? >>>>> 2. Does it support the host architectures that QEMU runs on? >>>> >>>> Speaking of this, I was thinking that we should introduce >>>> a rule that for any host OS/arch we support we must have >>>> a build machine so we can at least do a compile test. >>>> For instance if you believe configure we support Solaris >>>> and AIX, but I bet they're bit-rotting. The ia64 backend >>>> has to be a strong candidate for being dumped too. >>>> Demanding "system we can test on or we drop support" >>>> would let us more clearly see what we're actually running >>>> on and avoid unnecessarily ruling things out because they >>>> don't support Itanium or AIX... >>> >>> YES, YES and YES. >>> >>> I demand an osX build machine NOW!!!! Remote access is ok. >>> >>> Now more seriously, I can (relatively easy) compile test my pull >>> requests with: >>> - linux x86 (latest fedora, but I can get an older one if needed) >>> - linux x86_64 (latest fedor,, but the same) >>> - mingw64 32bit (latest fedora, but here I have the problem that Peter >>> uses a different crosscompiler than me) >>> - mingw64 32bit (the same) >>> >>> But for the rest, I need to wait that somebody told me that it breaks >>> the build. Normally it is things like size_t is 32bit instead of 64bit >>> or some stupid things like that, that are trivial to fix if I can >>> compile there before doing the pull submission. >> >> I also do a FreeBSD VM, and grab an aarch64 and/or PPC bigendian host >> to test on. >> >> (I could grab an ia64 host, but I don't think I could find anything >> to install on it that would be new enough for the rest of our build >> requirements). > > Indeed, ia64 is a fully dead as a host architecture at this point, only > interesting as a historical curiosity. Paolo already killed ia64 KVM > host support in Linux git back in 2014. Our ia64 host backend in QEMU (tcg/ia64) is still marked as maintained ... so it's maybe not as dead as you think? Or should we rather get rid of that soon, too? Thomas From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnpis-0001um-F8 for qemu-devel@nongnu.org; Tue, 14 Mar 2017 12:54:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cnpip-0000Vp-8X for qemu-devel@nongnu.org; Tue, 14 Mar 2017 12:54:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46206) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cnpio-0000Vd-Vu for qemu-devel@nongnu.org; Tue, 14 Mar 2017 12:54:55 -0400 References: <87tw6y8bs8.fsf@secure.mitica> <20170314081312.GB13140@stefanha-x1.localdomain> <87wpbstesf.fsf@secure.mitica> <20170314160113.GM2445@work-vm> <20170314162020.GT2652@redhat.com> From: Thomas Huth Message-ID: Date: Tue, 14 Mar 2017 17:54:43 +0100 MIME-Version: 1.0 In-Reply-To: <20170314162020.GT2652@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Obsolete QEMU host environments (was: Re: KVM call for 2017-03-14) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , "Dr. David Alan Gilbert" Cc: Juan Quintela , Peter Maydell , QEMU Developer , KVM devel mailing list , Stefan Hajnoczi , Richard Henderson , Aurelien Jarno On 14.03.2017 17:20, Daniel P. Berrange wrote: > On Tue, Mar 14, 2017 at 04:01:14PM +0000, Dr. David Alan Gilbert wrote: >> * Juan Quintela (quintela@redhat.com) wrote: >>> Peter Maydell wrote: >>>> On 14 March 2017 at 09:13, Stefan Hajnoczi wrote: >>>>> On Mon, Mar 13, 2017 at 11:02:01AM +0100, Peter Maydell wrote: >>>>> The minimum requirements for the new language: >>>>> 1. Does it support the host operating systems that QEMU runs on? >>>>> 2. Does it support the host architectures that QEMU runs on? >>>> >>>> Speaking of this, I was thinking that we should introduce >>>> a rule that for any host OS/arch we support we must have >>>> a build machine so we can at least do a compile test. >>>> For instance if you believe configure we support Solaris >>>> and AIX, but I bet they're bit-rotting. The ia64 backend >>>> has to be a strong candidate for being dumped too. >>>> Demanding "system we can test on or we drop support" >>>> would let us more clearly see what we're actually running >>>> on and avoid unnecessarily ruling things out because they >>>> don't support Itanium or AIX... >>> >>> YES, YES and YES. >>> >>> I demand an osX build machine NOW!!!! Remote access is ok. >>> >>> Now more seriously, I can (relatively easy) compile test my pull >>> requests with: >>> - linux x86 (latest fedora, but I can get an older one if needed) >>> - linux x86_64 (latest fedor,, but the same) >>> - mingw64 32bit (latest fedora, but here I have the problem that Peter >>> uses a different crosscompiler than me) >>> - mingw64 32bit (the same) >>> >>> But for the rest, I need to wait that somebody told me that it breaks >>> the build. Normally it is things like size_t is 32bit instead of 64bit >>> or some stupid things like that, that are trivial to fix if I can >>> compile there before doing the pull submission. >> >> I also do a FreeBSD VM, and grab an aarch64 and/or PPC bigendian host >> to test on. >> >> (I could grab an ia64 host, but I don't think I could find anything >> to install on it that would be new enough for the rest of our build >> requirements). > > Indeed, ia64 is a fully dead as a host architecture at this point, only > interesting as a historical curiosity. Paolo already killed ia64 KVM > host support in Linux git back in 2014. Our ia64 host backend in QEMU (tcg/ia64) is still marked as maintained ... so it's maybe not as dead as you think? Or should we rather get rid of that soon, too? Thomas