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

Re: [PATCH 1/2] docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386



"Michael S. Tsirkin" <mst@xxxxxxxxxx> writes:

> On Tue, Feb 28, 2023 at 09:40:49AM +0000, Daniel P. Berrangé wrote:
>> On Tue, Feb 28, 2023 at 10:14:52AM +0100, Thomas Huth wrote:
>> > On 28/02/2023 10.03, Michael S. Tsirkin wrote:
>> > > On Tue, Feb 28, 2023 at 08:59:52AM +0000, Daniel P. Berrangé wrote:
>> > > > On Tue, Feb 28, 2023 at 03:19:20AM -0500, Michael S. Tsirkin wrote:
>> > > > > On Tue, Feb 28, 2023 at 08:49:09AM +0100, Thomas Huth wrote:
>> > > > > > On 27/02/2023 21.12, Michael S. Tsirkin wrote:
>> > > > > > > On Mon, Feb 27, 2023 at 11:50:07AM +0000, Daniel P. Berrangé 
>> > > > > > > wrote:
>> > > > > > > > I feel like we should have separate deprecation entries for the
>> > > > > > > > i686 host support, and for qemu-system-i386 emulator binary, as
>> > > > > > > > although they're related they are independant features with
>> > > > > > > > differing impact. eg removing qemu-system-i386 affects all
>> > > > > > > > host architectures, not merely 32-bit x86 host, so I think we
>> > > > > > > > can explain the impact more clearly if we separate them.
>> > > > > > > 
>> > > > > > > Removing qemu-system-i386 seems ok to me - I think 
>> > > > > > > qemu-system-x86_64 is
>> > > > > > > a superset.
>> > > > > > > 
>> > > > > > > Removing support for building on 32 bit systems seems like a 
>> > > > > > > pity - it's
>> > > > > > > one of a small number of ways to run 64 bit binaries on 32 bit 
>> > > > > > > systems,
>> > > > > > > and the maintainance overhead is quite small.
>> > > > > > 
>> > > > > > Note: We're talking about 32-bit *x86* hosts here. Do you really 
>> > > > > > think that
>> > > > > > someone is still using QEMU usermode emulation
>> > > > > > to run 64-bit binaries on a 32-bit x86 host?? ... If so, I'd be 
>> > > > > > very surprised!
>> > > > > 
>> > > > > I don't know - why x86 specifically? One can build a 32 bit binary 
>> > > > > on any host.
>> > > > > I think 32 bit x86 environments are just more common in the cloud.
>> > > > 
>> > > > Can you point to anything that backs up that assertion. Clouds I've
>> > > > seen always give you a 64-bit environment, and many OS no longer
>> > > > even ship 32-bit installable media.
>> > > 
>> > > Sorry about being unclear. I meant that it seems easier to run CI in the
>> > > cloud in a 32 bit x64 environment than get a 32 bit ARM environment.
>> > 
>> > It's still doable ... but for how much longer? We're currently depending on
>> > Fedora, but they also slowly drop more and more support for this
>> > environment, see e.g.:
>> 
>> FWIW, we should cull our fedora-i386-cross.docker dockerfile and
>> replace it with a debian i686 dockerfile generated by lcitool.
>> There's no compelling reason why i686 should be different from
>> all our other cross builds which are based on Debian. The Debian
>> lcitool generated container would have access to a wider range
>> of deps than our hand written Fedora one.
>> 
>> >  https://www.theregister.com/2022/03/10/fedora_inches_closer_to_dropping/
>> 
>> With regards,
>> Daniel
>
> ... and is closer to where 32 bit is likely to be deployed which is
> systems like e.g. raspberry pi os which until recently was only
> 32 bit.

32 bit ARM.  How is that an argument for continued maintenance of 32 bit
x86?

If the argument goes like "32 bit x86 is easier to test in CI", then I
don't buy it.  Testing 64 bit ARM + 32 bit x86 does not magically
replace testing 32 bit ARM.

The question to answer: Is 32 bit x86 worth its upkeep?  Two
sub-questions: 1. Is it worth the human attention?  2. Is it worth
(scarce!) CI minutes?

I want to see an argument for benefits justifying the costs.

A benefit like "somebody out there might still want to use it" I'd value
at zero.




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.