Obsolete QEMU host environments (was: Re: KVM call for 2017-03-14)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx) wrote:
>>> Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
>>>> On 14 March 2017 at 09:13, Stefan Hajnoczi <stefanha@xxxxxxxxx> 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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux