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

[Markus Armbruster <armbru@redhat.com>]

"Michael S. Tsirkin" <mst@redhat.com> 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.