Re: dropping 32-bit host support

Re: dropping 32-bit host support

[Philippe Mathieu-Daudé]

Hi Andrew,

On 16/3/23 01:57, Andrew Randrianasulu wrote:
> Looking at https://wiki.qemu.org/ChangeLog/8.0 
> <https://wiki.qemu.org/ChangeLog/8.0>
> 
> ===
> System emulation on 32-bit x86 and ARM hosts has been deprecated. The 
> QEMU project no longer considers 32-bit x86 and ARM support for system 
> emulation to be an effective use of its limited resources, and thus 
> intends to discontinue.
> 
>   ==
> 
> well, I guess arguing from memory-consuption point on 32 bit x86 hosts 
> (like my machine where I run 32 bit userspace on 64 bit kernel) is not 

If you use a 64-bit kernel, then your host is 64-bit :)

host: hardware where you run QEMU
guest: what is run within QEMU

Running 32-bit *guest* on your 64-bit *host* is still supported.

We don't plan to support running 32-bit WinXP x86 (guest) on 32-bit
Raspberry Pi 2 (host) for example.

> going anywhere, but what about 32bit userspace on Android tablets, 
> either via Limbo emulator or qemu itself in Termux?

*System* emulation [on 32-bit hosts] is deprecated. User emulation
(such linux-user) is not. For example, you can still run 64-bit x86_64
Linux binaries on a 32-bit ARM Raspberry Pi.

> At least I hope it will be not *actively* (intentionally) broken, just 
> ...unsupported (so users who know how to run git revert still will get 
> their build for some more time).

Unsupported code almost always unintentionally end bit-rotting...

I hope this is clearer.

Regards,

Phil.

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé <philmd@linaro.org>:

> Hi Andrew,
>
> On 16/3/23 01:57, Andrew Randrianasulu wrote:
> > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > <https://wiki.qemu.org/ChangeLog/8.0>
> >
> > ===
> > System emulation on 32-bit x86 and ARM hosts has been deprecated. The
> > QEMU project no longer considers 32-bit x86 and ARM support for system
> > emulation to be an effective use of its limited resources, and thus
> > intends to discontinue.
> >
> >   ==
> >
> > well, I guess arguing from memory-consuption point on 32 bit x86 hosts
> > (like my machine where I run 32 bit userspace on 64 bit kernel) is not
>
> If you use a 64-bit kernel, then your host is 64-bit :)
>


No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit. So,
qemu naturally will be 32-bit binary on my system.



> host: hardware where you run QEMU
> guest: what is run within QEMU
>
> Running 32-bit *guest* on your 64-bit *host* is still supported.
>
> We don't plan to support running 32-bit WinXP x86 (guest) on 32-bit
> Raspberry Pi 2 (host) for example.
>
> > going anywhere, but what about 32bit userspace on Android tablets,
> > either via Limbo emulator or qemu itself in Termux?
>
> *System* emulation [on 32-bit hosts] is deprecated. User emulation
> (such linux-user) is not. For example, you can still run 64-bit x86_64
> Linux binaries on a 32-bit ARM Raspberry Pi.
>


Well, unrooted Android does not allow you to just load some perfectly fine
kernel module, so user-space emulation can't do all things system-level one
can. I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Android, too)
for emulating old mac os 9. Yes, I can wait 10 min per guest boot. Fedora
36 armhf boots even slower on emulation!


> > At least I hope it will be not *actively* (intentionally) broken, just
> > ...unsupported (so users who know how to run git revert still will get
> > their build for some more time).
>
> Unsupported code almost always unintentionally end bit-rotting...
>


Well, sometimes simple patch restores functionality. I patched for example
olive-editor to run on 32 bit, and before this intel embree (raytracing
kernels for Lux renderer). So, _sometimes_ it really not that costly. While
if this CI thing really runs per-commit and thrown away each result ... may
be letting interested users to build things on their own machines (and
share patches, if they develop them, publicly)  actually good idea.



> I hope this is clearer.
>
> Regards,
>
> Phil.
>

[-- Attachment #2: Type: text/html, Size: 4055 bytes --]

Re: dropping 32-bit host support

[Philippe Mathieu-Daudé]

Hi Liviu,

On 16/3/23 07:19, Liviu Ionescu wrote:
> 
> 
>> On 16 Mar 2023, at 02:57, Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
>>
>> Looking at https://wiki.qemu.org/ChangeLog/8.0
>>
>> ===
>> System emulation on 32-bit x86 and ARM hosts has been deprecated. The QEMU project no longer considers 32-bit x86 and ARM support for system emulation to be an effective use of its limited resources, and thus intends to discontinue.
>>
>>   ==
>>
>> well, I guess arguing from memory-consuption point on 32 bit x86 hosts (like my machine where I run 32 bit userspace on 64 bit kernel) is not going anywhere, but what about 32bit userspace on Android tablets, either via Limbo emulator or qemu itself in Termux?
> 
> or the countless 32-bit Raspberry Pi?
> 
> my xPack binary tools, which include qemu arm & qemu riscv, are also available for arm 32-bit, and the analytics show about the same number of downloads for 32-bit as for 64-bit.
> 
> given the current chip shortages, I estimate that the 32-bit Arm binaries will still be useful for a few more years.

IIUC xPack uses npm -- so work on any environment where npm works --,
and fetch/install existing toolchains. Looking at ARM, all offered
toolchains are 64-bit host [1] and the deprecated [2]. Toolchains for
32-bit hosts are still available but also listed as "deprecated" [3].

[1] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
[2] https://developer.arm.com/downloads/-/gnu-a
[3] https://developer.arm.com/downloads/-/gnu-rm

If QEMU is useful to you for testing installing xPack on a 32-bit
emulated guest, I strongly recommend you to do that on a 64-bit host
rather than a limited performance 32-bit Raspberry Pi 2, it is a much
more pleasant "user experience". IMHO Raspberry Pi 2 was designed for
embedded setup and prototyping with other electronic devices, not
really as a compute intensive build CPU.

>> At least I hope it will be not *actively* (intentionally) broken, just ...unsupported (so users who know how to run git revert still will get their build for some more time).
> 
> I concur, please do not intentionally break support for arm 32-bit, this will make a lot of unhappy users, who currently have no choice to upgrade.
> 
> 
> thank you,
> 
> Liviu

Regards,

Phil.

Re: dropping 32-bit host support

[Philippe Mathieu-Daudé]

On 16/3/23 08:17, Andrew Randrianasulu wrote:
> 
> 
> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé <philmd@linaro.org 
> <mailto:philmd@linaro.org>>:
> 
>     Hi Andrew,
> 
>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
>     <https://wiki.qemu.org/ChangeLog/8.0>
>      > <https://wiki.qemu.org/ChangeLog/8.0
>     <https://wiki.qemu.org/ChangeLog/8.0>>
>      >
>      > ===
>      > System emulation on 32-bit x86 and ARM hosts has been deprecated.
>     The
>      > QEMU project no longer considers 32-bit x86 and ARM support for
>     system
>      > emulation to be an effective use of its limited resources, and thus
>      > intends to discontinue.
>      >
>      >   ==
>      >
>      > well, I guess arguing from memory-consuption point on 32 bit x86
>     hosts
>      > (like my machine where I run 32 bit userspace on 64 bit kernel)
>     is not
> 
>     If you use a 64-bit kernel, then your host is 64-bit :)
> 
> 
> 
> No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit. 
> So, qemu naturally will be 32-bit binary on my system.

This configuration is still supported!

Thomas, should we clarify yet again? Maybe adding examples?

>     host: hardware where you run QEMU
>     guest: what is run within QEMU
> 
>     Running 32-bit *guest* on your 64-bit *host* is still supported.
> 
>     We don't plan to support running 32-bit WinXP x86 (guest) on 32-bit
>     Raspberry Pi 2 (host) for example.
> 
>      > going anywhere, but what about 32bit userspace on Android tablets,
>      > either via Limbo emulator or qemu itself in Termux?
> 
>     *System* emulation [on 32-bit hosts] is deprecated. User emulation
>     (such linux-user) is not. For example, you can still run 64-bit x86_64
>     Linux binaries on a 32-bit ARM Raspberry Pi.
> 
> 
> 
> Well, unrooted Android does not allow you to just load some perfectly 
> fine kernel module, so user-space emulation can't do all things 
> system-level one can. I also ran qemu-system-ppc on Huawei Matepad T8 
> (32 bit Android, too) for emulating old mac os 9. Yes, I can wait 10 min 
> per guest boot. Fedora 36 armhf boots even slower on emulation!

Huawei MatePad T8 is based on a MediaTek MT8768 CPU which contains
ARM Cortex-A53 cores. These cores implements the ARMv8-A 64-bit ISA,
so theoretically it is able to run a 64-bit Android.

>      > At least I hope it will be not *actively* (intentionally) broken,
>     just
>      > ...unsupported (so users who know how to run git revert still
>     will get
>      > their build for some more time).
> 
>     Unsupported code almost always unintentionally end bit-rotting...
> 
> 
> 
> Well, sometimes simple patch restores functionality. I patched for 
> example olive-editor to run on 32 bit, and before this intel embree 
> (raytracing kernels for Lux renderer). So, _sometimes_ it really not 
> that costly. While if this CI thing really runs per-commit and thrown 
> away each result ... may be letting interested users to build things on 
> their own machines (and share patches, if they develop them, publicly)  
> actually good idea.
> 
> 
> 
>     I hope this is clearer.
> 
>     Regards,
> 
>     Phil.
> 

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 3995 bytes --]

чт, 16 мар. 2023 г., 10:36 Philippe Mathieu-Daudé <philmd@linaro.org>:

> On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >
> >
> > чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé <philmd@linaro.org
> > <mailto:philmd@linaro.org>>:
> >
> >     Hi Andrew,
> >
> >     On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >      > Looking at https://wiki.qemu.org/ChangeLog/8.0
> >     <https://wiki.qemu.org/ChangeLog/8.0>
> >      > <https://wiki.qemu.org/ChangeLog/8.0
> >     <https://wiki.qemu.org/ChangeLog/8.0>>
> >      >
> >      > ===
> >      > System emulation on 32-bit x86 and ARM hosts has been deprecated.
> >     The
> >      > QEMU project no longer considers 32-bit x86 and ARM support for
> >     system
> >      > emulation to be an effective use of its limited resources, and
> thus
> >      > intends to discontinue.
> >      >
> >      >   ==
> >      >
> >      > well, I guess arguing from memory-consuption point on 32 bit x86
> >     hosts
> >      > (like my machine where I run 32 bit userspace on 64 bit kernel)
> >     is not
> >
> >     If you use a 64-bit kernel, then your host is 64-bit :)
> >
> >
> >
> > No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit.
> > So, qemu naturally will be 32-bit binary on my system.
>
> This configuration is still supported!
>
> Thomas, should we clarify yet again? Maybe adding examples?
>
> >     host: hardware where you run QEMU
> >     guest: what is run within QEMU
> >
> >     Running 32-bit *guest* on your 64-bit *host* is still supported.
> >
> >     We don't plan to support running 32-bit WinXP x86 (guest) on 32-bit
> >     Raspberry Pi 2 (host) for example.
> >
> >      > going anywhere, but what about 32bit userspace on Android tablets,
> >      > either via Limbo emulator or qemu itself in Termux?
> >
> >     *System* emulation [on 32-bit hosts] is deprecated. User emulation
> >     (such linux-user) is not. For example, you can still run 64-bit
> x86_64
> >     Linux binaries on a 32-bit ARM Raspberry Pi.
> >
> >
> >
> > Well, unrooted Android does not allow you to just load some perfectly
> > fine kernel module, so user-space emulation can't do all things
> > system-level one can. I also ran qemu-system-ppc on Huawei Matepad T8
> > (32 bit Android, too) for emulating old mac os 9. Yes, I can wait 10 min
> > per guest boot. Fedora 36 armhf boots even slower on emulation!
>
> Huawei MatePad T8 is based on a MediaTek MT8768 CPU which contains
> ARM Cortex-A53 cores. These cores implements the ARMv8-A 64-bit ISA,
> so theoretically it is able to run a 64-bit Android.
>

Good luck installing non-vendor Android on off the shelf device, also good
luck running 64bit Android in 2gb ram. To be honest yes before I had only
Android + termux setup for all my computer needs I cared less about
upstream removals - because I usually can revert things locally on
Slackware. But Termux is rolling distro, and there is not many
alternatives. So upstream decisions will hit here fast and hard.


> >      > At least I hope it will be not *actively* (intentionally) broken,
> >     just
> >      > ...unsupported (so users who know how to run git revert still
> >     will get
> >      > their build for some more time).
> >
> >     Unsupported code almost always unintentionally end bit-rotting...
> >
> >
> >
> > Well, sometimes simple patch restores functionality. I patched for
> > example olive-editor to run on 32 bit, and before this intel embree
> > (raytracing kernels for Lux renderer). So, _sometimes_ it really not
> > that costly. While if this CI thing really runs per-commit and thrown
> > away each result ... may be letting interested users to build things on
> > their own machines (and share patches, if they develop them, publicly)
> > actually good idea.
> >
> >
> >
> >     I hope this is clearer.
> >
> >     Regards,
> >
> >     Phil.
> >
>
>

[-- Attachment #2: Type: text/html, Size: 5705 bytes --]

Re: dropping 32-bit host support

[Liviu Ionescu]

> On 16 Mar 2023, at 09:29, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> 
> Hi Liviu,
> 
>> or the countless 32-bit Raspberry Pi?
>> my xPack binary tools, which include qemu arm & qemu riscv, are also available for arm 32-bit, and the analytics show about the same number of downloads for 32-bit as for 64-bit.
>> given the current chip shortages, I estimate that the 32-bit Arm binaries will still be useful for a few more years.
> 
> IIUC xPack uses npm -- so work on any environment where npm works --,
> and fetch/install existing toolchains.

xPacks use `xpm`, which is an extension of `npm`.

If handles C/C++ (actually any language) source packages, and binary packages.

> Looking at ARM, all offered
> toolchains are 64-bit host [1] and the deprecated [2]. Toolchains for
> 32-bit hosts are still available but also listed as "deprecated" [3].
> 
> [1] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
> [2] https://developer.arm.com/downloads/-/gnu-a
> [3] https://developer.arm.com/downloads/-/gnu-rm

Nope, xpm does not download the archives provided by ARM, it uses its own binaries:

- https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/blob/6f6917999b9bdd12c4159631f77ae08e10d2d7d2/package.json#L40-L67

There is a full set of development tools (arm/aarch64/riscv/gcc/mingw-gcc/clang toolchain, cmake/meson/ninja/qemu/etc) which all run on 32-bit Raspberry Pi.

- https://github.com/xpack-dev-tools

> If QEMU is useful to you for testing installing xPack on a 32-bit
> emulated guest, I strongly recommend you to do that on a 64-bit host
> rather than a limited performance 32-bit Raspberry Pi 2,

I'm not targeting RPi2; there are a lot of RPi4 with less than 8GB RAM (most of them, actually), and even more RPi3, with even less RAM), and people prefer to continue using the 32-bit OS on them, which works quite fine; all my development tools are available on them.


You might think this weird, but there are people who use berries as their only machine, including for software development, and qemu arm/riscv is an important tool for running some of the tests.

Regards,

Liviu

Re: dropping 32-bit host support

[Liviu Ionescu]

> On 16 Mar 2023, at 09:57, Liviu Ionescu <ilg@livius.net> wrote:
> 
> I'm not targeting RPi2; there are a lot of RPi4 with less than 8GB RAM (most of them, actually), and even more RPi3, with even less RAM), and people prefer to continue using the 32-bit OS on them, which works quite fine;

Like it or not, as long as Raspberry does not explicitly deprecate the 32-bit OS, people will continue to use it, and for good reasons.

As of now, it is even 'Our recommended operating system for most users.':

- https://www.raspberrypi.com/software/operating-systems/


Regards,

Liviu

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> On 16/3/23 08:17, Andrew Randrianasulu wrote:
>>
>> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé <philmd@linaro.org 
>> <mailto:philmd@linaro.org>>:
>>
>>     Hi Andrew,
>>
>>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
>>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
>>     <https://wiki.qemu.org/ChangeLog/8.0>
>>      > <https://wiki.qemu.org/ChangeLog/8.0
>>     <https://wiki.qemu.org/ChangeLog/8.0>>
>>      >
>>      > ===
>>      > System emulation on 32-bit x86 and ARM hosts has been deprecated.
>>     The
>>      > QEMU project no longer considers 32-bit x86 and ARM support for
>>     system
>>      > emulation to be an effective use of its limited resources, and thus
>>      > intends to discontinue.
>>      >
>>      >   ==
>>      >
>>      > well, I guess arguing from memory-consuption point on 32 bit x86
>>     hosts
>>      > (like my machine where I run 32 bit userspace on 64 bit kernel)

All current PCs have multiple gigabytes of RAM, so using a 32-bit userspace 
to save some few bytes sounds weird.

(and in case you're talking about a very old PC that cannot be extened 
anymore, you're likely better off with an older version of QEMU anyway)

>>
>>     If you use a 64-bit kernel, then your host is 64-bit :)
>>
>>
>>
>> No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit. 
>> So, qemu naturally will be 32-bit binary on my system.
> 
> This configuration is still supported!
> 
> Thomas, should we clarify yet again? Maybe adding examples?

There are two aspects here:

1) 32-bit KVM support - this won't be supported in the future anymore. Since 
running a 32-bit QEMU on a 64-bit kernel still uses the 32-bit KVM API, KVM 
also won't be possible anymore with a QEMU that has been compiled in 32-bit 
mode.

2) Compiling a 32-bit QEMU binary won't be officially supported anymore. We 
won't waste any more precious CI minutes on this (which is where we're 
struggling the most currently), and likely no active support for finding and 
fixing bugs. But I guess we won't actively disable this possibility 
(especially since we did not deprecate the corresponding 32-bit linux-user 
emulation yet, so the emulation code will mostly still stay around).

In the long run, we likely want to get rid of the separate compilation of 
the qemu-system-i386 binary, too, but that's still to be discussed. E.g. we 
could add a special run mode to the qemu-system-x86_64 instead that makes 
sure that the guest can only run in 32-bit mode.

>>     host: hardware where you run QEMU
>>     guest: what is run within QEMU
>>
>>     Running 32-bit *guest* on your 64-bit *host* is still supported.

If the complete userspace is 32-bit, I'd rather consider it a 32-bit host.

>> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Android, 
>> too) for emulating old mac os 9. Yes, I can wait 10 min per guest boot. 
>> Fedora 36 armhf boots even slower on emulation!

Yes, but for such scenarios, you can also use older versions of QEMU, you 
don't need the latest and greatest shiny QEMU version.

>> Well, sometimes simple patch restores functionality. I patched for example 
>> olive-editor to run on 32 bit, and before this intel embree (raytracing 
>> kernels for Lux renderer). So, _sometimes_ it really not that costly. 
>> While if this CI thing really runs per-commit and thrown away each result 
>> ... may be letting interested users to build things on their own machines 
>> (and share patches, if they develop them, publicly) actually good idea.

The problem is really that we don't have unlimited resources in the QEMU 
project. Currently we're heavily struggling with the load in the CI, but 
also pure man power is always very scarce. So at one point in time, you have 
to decide to say good bye to some old and hardly used features - at least to 
stop testing and actively supporting it. If you want to continue testing and 
fixing bugs for such host systems, that's fine, of course, but don't expect 
the QEMU developers to do that job in the future.

  Thomas

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 09.07, Liviu Ionescu wrote:
> 
> 
>> On 16 Mar 2023, at 09:57, Liviu Ionescu <ilg@livius.net> wrote:
>>
>> I'm not targeting RPi2; there are a lot of RPi4 with less than 8GB RAM (most of them, actually), and even more RPi3, with even less RAM), and people prefer to continue using the 32-bit OS on them, which works quite fine;
> 
> Like it or not, as long as Raspberry does not explicitly deprecate the 32-bit OS, people will continue to use it, and for good reasons.
> 
> As of now, it is even 'Our recommended operating system for most users.':

I'd say "most users" != "the people who want to run QEMU here". If you 
really really want to run QEMU on such a system, you can also install a 
64-bit OS there.

Please also consider that we're only talking about marking the 32-bit arm 
hosts as deprecated in our docs right now. It will take another year (or 
maybe more) until the deprecation will turn into a real unsupported state. I 
assume by that point in time, more and more RPi users will have switched to 
a 64-bit OS instead.

  Thomas

Re: dropping 32-bit host support

[Liviu Ionescu]

> On 16 Mar 2023, at 10:36, Thomas Huth <thuth@redhat.com> wrote:
> 
> ... It will take another year (or maybe more) until the deprecation will turn into a real unsupported state. I assume by that point in time, more and more RPi users will have switched to a 64-bit OS instead.

There is an easy and accurate way to know this, if by that time Raspberry no longer recommends the 32-bit OS, it is time to switch to 64-bit.


Regards,

Liviu

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 4732 bytes --]

чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com>:

> On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >>
> >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé <philmd@linaro.org
> >> <mailto:philmd@linaro.org>>:
> >>
> >>     Hi Andrew,
> >>
> >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
> >>     <https://wiki.qemu.org/ChangeLog/8.0>
> >>      > <https://wiki.qemu.org/ChangeLog/8.0
> >>     <https://wiki.qemu.org/ChangeLog/8.0>>
> >>      >
> >>      > ===
> >>      > System emulation on 32-bit x86 and ARM hosts has been deprecated.
> >>     The
> >>      > QEMU project no longer considers 32-bit x86 and ARM support for
> >>     system
> >>      > emulation to be an effective use of its limited resources, and
> thus
> >>      > intends to discontinue.
> >>      >
> >>      >   ==
> >>      >
> >>      > well, I guess arguing from memory-consuption point on 32 bit x86
> >>     hosts
> >>      > (like my machine where I run 32 bit userspace on 64 bit kernel)
>
> All current PCs have multiple gigabytes of RAM, so using a 32-bit
> userspace
> to save some few bytes sounds weird.
>

I think difference more like in 20-30% (on disk and in ram), not *few
bytes*. Also, this whole "my program is only one running on user's
machine"  is flawed.



> (and in case you're talking about a very old PC that cannot be extened
> anymore, you're likely better off with an older version of QEMU anyway)
>
> >>
> >>     If you use a 64-bit kernel, then your host is 64-bit :)
> >>
> >>
> >>
> >> No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit.
> >> So, qemu naturally will be 32-bit binary on my system.
> >
> > This configuration is still supported!
> >
> > Thomas, should we clarify yet again? Maybe adding examples?
>
> There are two aspects here:
>
> 1) 32-bit KVM support - this won't be supported in the future anymore.
> Since
> running a 32-bit QEMU on a 64-bit kernel still uses the 32-bit KVM API,
> KVM
> also won't be possible anymore with a QEMU that has been compiled in
> 32-bit
> mode.
>
> 2) Compiling a 32-bit QEMU binary won't be officially supported anymore.
> We
> won't waste any more precious CI minutes on this (which is where we're
> struggling the most currently), and likely no active support for finding
> and
> fixing bugs.


Well, does this CI thing reuse build objects (even indirectly, via ccache)
currently?


But I guess we won't actively disable this possibility
> (especially since we did not deprecate the corresponding 32-bit linux-user
> emulation yet, so the emulation code will mostly still stay around).
>
> In the long run, we likely want to get rid of the separate compilation of
> the qemu-system-i386 binary, too, but that's still to be discussed. E.g.
> we
> could add a special run mode to the qemu-system-x86_64 instead that makes
> sure that the guest can only run in 32-bit mode.
>
> >>     host: hardware where you run QEMU
> >>     guest: what is run within QEMU
> >>
> >>     Running 32-bit *guest* on your 64-bit *host* is still supported.
>
> If the complete userspace is 32-bit, I'd rather consider it a 32-bit host.
>
> >> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Android,
> >> too) for emulating old mac os 9. Yes, I can wait 10 min per guest boot.
> >> Fedora 36 armhf boots even slower on emulation!
>
> Yes, but for such scenarios, you can also use older versions of QEMU, you
> don't need the latest and greatest shiny QEMU version.
>
> >> Well, sometimes simple patch restores functionality. I patched for
> example
> >> olive-editor to run on 32 bit, and before this intel embree (raytracing
> >> kernels for Lux renderer). So, _sometimes_ it really not that costly.
> >> While if this CI thing really runs per-commit and thrown away each
> result
> >> ... may be letting interested users to build things on their own
> machines
> >> (and share patches, if they develop them, publicly) actually good idea.
>
> The problem is really that we don't have unlimited resources in the QEMU
> project. Currently we're heavily struggling with the load in the CI, but
> also pure man power is always very scarce. So at one point in time, you
> have
> to decide to say good bye to some old and hardly used features - at least
> to
> stop testing and actively supporting it. If you want to continue testing
> and
> fixing bugs for such host systems, that's fine, of course, but don't
> expect
> the QEMU developers to do that job in the future.
>
>   Thomas
>
>

[-- Attachment #2: Type: text/html, Size: 6746 bytes --]

Re: dropping 32-bit host support

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

[...]

> The problem is really that we don't have unlimited resources in the
> QEMU project. Currently we're heavily struggling with the load in the
> CI, but also pure man power is always very scarce. So at one point in
> time, you have to decide to say good bye to some old and hardly used
> features - at least to stop testing and actively supporting it. If you
> want to continue testing and fixing bugs for such host systems, that's
> fine, of course, but don't expect the QEMU developers to do that job
> in the future.

This.

We're out of free lunch.  We're glad you enjoyed it while it lasted.

If you want more lunch, you need to join the kitchen.  Here are a few
things we need to keep a host or target supported:

* Competent maintainer(s) to relieve the ones who have maintained this
  for you so far

* CI runners to conserve scarce CI minutes (or the money to buy more)

* Trustworthy system administrator(s) to set them up and keep them
  running.

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

чт, 16 мар. 2023 г., 13:01 Markus Armbruster <armbru@redhat.com>:

> Thomas Huth <thuth@redhat.com> writes:
>
> [...]
>
> > The problem is really that we don't have unlimited resources in the
> > QEMU project. Currently we're heavily struggling with the load in the
> > CI, but also pure man power is always very scarce. So at one point in
> > time, you have to decide to say good bye to some old and hardly used
> > features - at least to stop testing and actively supporting it. If you
> > want to continue testing and fixing bugs for such host systems, that's
> > fine, of course, but don't expect the QEMU developers to do that job
> > in the future.
>
> This.
>
> We're out of free lunch.  We're glad you enjoyed it while it lasted.
>
> If you want more lunch, you need to join the kitchen.  Here are a few
> things we need to keep a host or target supported:
>
> * Competent maintainer(s) to relieve the ones who have maintained this
>   for you so far
>
> * CI runners to conserve scarce CI minutes (or the money to buy more)
>
> * Trustworthy system administrator(s) to set them up and keep them
>   running.
>


* Four - different developer culture, like, a bit fewer commits to run CI
with ? :)



>

[-- Attachment #2: Type: text/html, Size: 2000 bytes --]

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 6158 bytes --]

чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <randrianasulu@gmail.com>:

>
>
> чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com>:
>
>> On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
>> > On 16/3/23 08:17, Andrew Randrianasulu wrote:
>> >>
>> >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé <philmd@linaro.org
>> >> <mailto:philmd@linaro.org>>:
>> >>
>> >>     Hi Andrew,
>> >>
>> >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
>> >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
>> >>     <https://wiki.qemu.org/ChangeLog/8.0>
>> >>      > <https://wiki.qemu.org/ChangeLog/8.0
>> >>     <https://wiki.qemu.org/ChangeLog/8.0>>
>> >>      >
>> >>      > ===
>> >>      > System emulation on 32-bit x86 and ARM hosts has been
>> deprecated.
>> >>     The
>> >>      > QEMU project no longer considers 32-bit x86 and ARM support for
>> >>     system
>> >>      > emulation to be an effective use of its limited resources, and
>> thus
>> >>      > intends to discontinue.
>> >>      >
>> >>      >   ==
>> >>      >
>> >>      > well, I guess arguing from memory-consuption point on 32 bit x86
>> >>     hosts
>> >>      > (like my machine where I run 32 bit userspace on 64 bit kernel)
>>
>> All current PCs have multiple gigabytes of RAM, so using a 32-bit
>> userspace
>> to save some few bytes sounds weird.
>>
>
> I think difference more like in 20-30% (on disk and in ram), not *few
> bytes*.
>

I stand (self) corrected on *on disk* binary size, this parameter tend to
be ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I do
not have full identical x64 Slackware setup for measuring memory impact.


Still, pushing users into endless hw upgrade is no fun:

https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/

note e-waste and energy consumption

This graph does not make me happy:

https://ourworldindata.org/grapher/global-energy-substitution?time=earliest..2021

Note this paradox too

https://en.m.wikipedia.org/wiki/Jevons_paradox

Yes, weirdly or not basically I talk about same thing as "we are running
out of CI  quota". But. With ~all developers following mindlessly into
"upgrade now, think later if at all" whole dependency tree will be heavier
and heavier.


I guess whole move to gitlab also was not from overly good life .... I
wonder of those c:\ paths I saw while looking into build status  are real
and mean CI running on Windows? Or it was just some strange fake thing
..... is Windows cheaper? Is it really better when it comes to containers?



Also, this whole "my program is only one running on user's machine"  is
> flawed.
>
>
>
>> (and in case you're talking about a very old PC that cannot be extened
>> anymore, you're likely better off with an older version of QEMU anyway)
>>
>> >>
>> >>     If you use a 64-bit kernel, then your host is 64-bit :)
>> >>
>> >>
>> >>
>> >> No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all
>> 32bit.
>> >> So, qemu naturally will be 32-bit binary on my system.
>> >
>> > This configuration is still supported!
>> >
>> > Thomas, should we clarify yet again? Maybe adding examples?
>>
>> There are two aspects here:
>>
>> 1) 32-bit KVM support - this won't be supported in the future anymore.
>> Since
>> running a 32-bit QEMU on a 64-bit kernel still uses the 32-bit KVM API,
>> KVM
>> also won't be possible anymore with a QEMU that has been compiled in
>> 32-bit
>> mode.
>>
>> 2) Compiling a 32-bit QEMU binary won't be officially supported anymore.
>> We
>> won't waste any more precious CI minutes on this (which is where we're
>> struggling the most currently), and likely no active support for finding
>> and
>> fixing bugs.
>
>
> Well, does this CI thing reuse build objects (even indirectly, via ccache)
> currently?
>
>
> But I guess we won't actively disable this possibility
>> (especially since we did not deprecate the corresponding 32-bit
>> linux-user
>> emulation yet, so the emulation code will mostly still stay around).
>>
>> In the long run, we likely want to get rid of the separate compilation of
>> the qemu-system-i386 binary, too, but that's still to be discussed. E.g.
>> we
>> could add a special run mode to the qemu-system-x86_64 instead that makes
>> sure that the guest can only run in 32-bit mode.
>>
>> >>     host: hardware where you run QEMU
>> >>     guest: what is run within QEMU
>> >>
>> >>     Running 32-bit *guest* on your 64-bit *host* is still supported.
>>
>> If the complete userspace is 32-bit, I'd rather consider it a 32-bit host.
>>
>> >> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Android,
>> >> too) for emulating old mac os 9. Yes, I can wait 10 min per guest
>> boot.
>> >> Fedora 36 armhf boots even slower on emulation!
>>
>> Yes, but for such scenarios, you can also use older versions of QEMU, you
>> don't need the latest and greatest shiny QEMU version.
>>
>> >> Well, sometimes simple patch restores functionality. I patched for
>> example
>> >> olive-editor to run on 32 bit, and before this intel embree
>> (raytracing
>> >> kernels for Lux renderer). So, _sometimes_ it really not that costly.
>> >> While if this CI thing really runs per-commit and thrown away each
>> result
>> >> ... may be letting interested users to build things on their own
>> machines
>> >> (and share patches, if they develop them, publicly) actually good idea.
>>
>> The problem is really that we don't have unlimited resources in the QEMU
>> project. Currently we're heavily struggling with the load in the CI, but
>> also pure man power is always very scarce. So at one point in time, you
>> have
>> to decide to say good bye to some old and hardly used features - at least
>> to
>> stop testing and actively supporting it. If you want to continue testing
>> and
>> fixing bugs for such host systems, that's fine, of course, but don't
>> expect
>> the QEMU developers to do that job in the future.
>>
>>   Thomas
>>
>>

[-- Attachment #2: Type: text/html, Size: 9824 bytes --]

Re: dropping 32-bit host support

[Philippe Mathieu-Daudé]

On 16/3/23 11:22, Andrew Randrianasulu wrote:
> чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <randrianasulu@gmail.com 
> <mailto:randrianasulu@gmail.com>>:
>     чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com
>     <mailto:thuth@redhat.com>>:
>         On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
>          > On 16/3/23 08:17, Andrew Randrianasulu wrote:
>          >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
>         <philmd@linaro.org <mailto:philmd@linaro.org>
>          >> <mailto:philmd@linaro.org <mailto:philmd@linaro.org>>>:
>          >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
>          >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
>         <https://wiki.qemu.org/ChangeLog/8.0>
>          >>     <https://wiki.qemu.org/ChangeLog/8.0
>         <https://wiki.qemu.org/ChangeLog/8.0>>
>          >>      > <https://wiki.qemu.org/ChangeLog/8.0
>         <https://wiki.qemu.org/ChangeLog/8.0>
>          >>     <https://wiki.qemu.org/ChangeLog/8.0
>         <https://wiki.qemu.org/ChangeLog/8.0>>>
>          >>      >
>          >>      > ===
>          >>      > System emulation on 32-bit x86 and ARM hosts has been
>         deprecated.
>          >>     The
>          >>      > QEMU project no longer considers 32-bit x86 and ARM
>         support for
>          >>     system
>          >>      > emulation to be an effective use of its limited
>         resources, and thus
>          >>      > intends to discontinue.


> Still, pushing users into endless hw upgrade is no fun:
> 
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/ <https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/>
> 
> note e-waste and energy consumption
> 
> This graph does not make me happy:
> 
> https://ourworldindata.org/grapher/global-energy-substitution?time=earliest..2021 <https://ourworldindata.org/grapher/global-energy-substitution?time=earliest..2021>
> 
> Note this paradox too
> 
> https://en.m.wikipedia.org/wiki/Jevons_paradox 
> <https://en.m.wikipedia.org/wiki/Jevons_paradox>


>          >> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32
>         bit Android,
>          >> too) for emulating old mac os 9. Yes, I can wait 10 min per
>         guest boot.
>          >> Fedora 36 armhf boots even slower on emulation!
> 
>         Yes, but for such scenarios, you can also use older versions of
>         QEMU, you
>         don't need the latest and greatest shiny QEMU version.

Thomas answer still applies: if you can use QEMU v8.0.0 to emulate
macOS 9 on your Huawei Matepad T8 with 32-bit Android, why worry
about trying to use future QEMU versions?

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> 
> 
> чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <randrianasulu@gmail.com 
> <mailto:randrianasulu@gmail.com>>:
> 
> 
> 
>     чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com
>     <mailto:thuth@redhat.com>>:
> 
>         On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
>          > On 16/3/23 08:17, Andrew Randrianasulu wrote:
>          >>
>          >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
>         <philmd@linaro.org <mailto:philmd@linaro.org>
>          >> <mailto:philmd@linaro.org <mailto:philmd@linaro.org>>>:
>          >>
>          >>     Hi Andrew,
>          >>
>          >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
>          >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
>         <https://wiki.qemu.org/ChangeLog/8.0>
>          >>     <https://wiki.qemu.org/ChangeLog/8.0
>         <https://wiki.qemu.org/ChangeLog/8.0>>
>          >>      > <https://wiki.qemu.org/ChangeLog/8.0
>         <https://wiki.qemu.org/ChangeLog/8.0>
>          >>     <https://wiki.qemu.org/ChangeLog/8.0
>         <https://wiki.qemu.org/ChangeLog/8.0>>>
>          >>      >
>          >>      > ===
>          >>      > System emulation on 32-bit x86 and ARM hosts has been
>         deprecated.
>          >>     The
>          >>      > QEMU project no longer considers 32-bit x86 and ARM
>         support for
>          >>     system
>          >>      > emulation to be an effective use of its limited
>         resources, and thus
>          >>      > intends to discontinue.
>          >>      >
>          >>      >   ==
>          >>      >
>          >>      > well, I guess arguing from memory-consuption point on 32
>         bit x86
>          >>     hosts
>          >>      > (like my machine where I run 32 bit userspace on 64 bit
>         kernel)
> 
>         All current PCs have multiple gigabytes of RAM, so using a 32-bit
>         userspace
>         to save some few bytes sounds weird.
> 
> 
>     I think difference more like in 20-30% (on disk and in ram), not *few
>     bytes*. 
> 
> 
> I stand (self) corrected on *on disk* binary size, this parameter tend to be 
> ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I do not 
> have full identical x64 Slackware setup for measuring memory impact.
> 
> 
> Still, pushing users into endless hw upgrade is no fun:
> 
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/ >
> 
> note e-waste and energy consumption

Now you're mixing things quite badly. That would be an argument in the years 
before 2010 maybe, when not everybody had a 64-bit processor in their PC 
yet, but it's been now more than 12 years that all recent Desktop processors 
feature 64-bit mode. So if QEMU stops supporting 32-bit x86 environments, 
this is not forcing you to buy a new hardware, since you're having a 64-bit 
hardware already anyway. If someone still has plain 32-bit x86 hardware 
around for their daily use, that's certainly not a piece of hardware you 
want to run QEMU on, since it's older than 12 years already, and thus not 
really strong enough to run a recent emulator in a recent way.

  Thomas

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 3745 bytes --]

чт, 16 мар. 2023 г., 13:56 Philippe Mathieu-Daudé <philmd@linaro.org>:

> On 16/3/23 11:22, Andrew Randrianasulu wrote:
> > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <randrianasulu@gmail.com
> > <mailto:randrianasulu@gmail.com>>:
> >     чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com
> >     <mailto:thuth@redhat.com>>:
> >         On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> >          > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >          >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> >         <philmd@linaro.org <mailto:philmd@linaro.org>
> >          >> <mailto:philmd@linaro.org <mailto:philmd@linaro.org>>>:
> >          >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >          >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
> >         <https://wiki.qemu.org/ChangeLog/8.0>
> >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> >         <https://wiki.qemu.org/ChangeLog/8.0>>
> >          >>      > <https://wiki.qemu.org/ChangeLog/8.0
> >         <https://wiki.qemu.org/ChangeLog/8.0>
> >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> >         <https://wiki.qemu.org/ChangeLog/8.0>>>
> >          >>      >
> >          >>      > ===
> >          >>      > System emulation on 32-bit x86 and ARM hosts has been
> >         deprecated.
> >          >>     The
> >          >>      > QEMU project no longer considers 32-bit x86 and ARM
> >         support for
> >          >>     system
> >          >>      > emulation to be an effective use of its limited
> >         resources, and thus
> >          >>      > intends to discontinue.
>
>
> > Still, pushing users into endless hw upgrade is no fun:
> >
> >
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> <
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> >
> >
> > note e-waste and energy consumption
> >
> > This graph does not make me happy:
> >
> >
> https://ourworldindata.org/grapher/global-energy-substitution?time=earliest..2021
> <
> https://ourworldindata.org/grapher/global-energy-substitution?time=earliest..2021
> >
> >
> > Note this paradox too
> >
> > https://en.m.wikipedia.org/wiki/Jevons_paradox
> > <https://en.m.wikipedia.org/wiki/Jevons_paradox>
>
>
> >          >> [...] I also ran qemu-system-ppc on Huawei Matepad T8 (32
> >         bit Android,
> >          >> too) for emulating old mac os 9. Yes, I can wait 10 min per
> >         guest boot.
> >          >> Fedora 36 armhf boots even slower on emulation!
> >
> >         Yes, but for such scenarios, you can also use older versions of
> >         QEMU, you
> >         don't need the latest and greatest shiny QEMU version.
>
> Thomas answer still applies: if you can use QEMU v8.0.0 to emulate
> macOS 9 on your Huawei Matepad T8 with 32-bit Android, why worry
> about trying to use future QEMU versions?
>

Because Termux (only one currently supported distro for bare Android, as
far as I know, everything else either unsupported or run under it, with
some space penalty due to not using Android's libraries) will update qemu
As Fast As Possible, being rolling release.


Again, I as maintainer/developer (due to our real developer  being dead
from road  incident) of cinelerra-gg I only can recommend to try your
favourite projects in somewhat constrained environment, I tweaked our build
system quite heavily simply because I was forced by device's constrains.

Also, for CI thing may be lessen compiler optimization levels at least for
some runs? And/or tweak ccache compression ....

>

[-- Attachment #2: Type: text/html, Size: 7223 bytes --]

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 4150 bytes --]

чт, 16 мар. 2023 г., 14:02 Thomas Huth <thuth@redhat.com>:

> On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> >
> >
> > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <randrianasulu@gmail.com
> > <mailto:randrianasulu@gmail.com>>:
> >
> >
> >
> >     чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com
> >     <mailto:thuth@redhat.com>>:
> >
> >         On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> >          > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> >          >>
> >          >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> >         <philmd@linaro.org <mailto:philmd@linaro.org>
> >          >> <mailto:philmd@linaro.org <mailto:philmd@linaro.org>>>:
> >          >>
> >          >>     Hi Andrew,
> >          >>
> >          >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
> >          >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
> >         <https://wiki.qemu.org/ChangeLog/8.0>
> >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> >         <https://wiki.qemu.org/ChangeLog/8.0>>
> >          >>      > <https://wiki.qemu.org/ChangeLog/8.0
> >         <https://wiki.qemu.org/ChangeLog/8.0>
> >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> >         <https://wiki.qemu.org/ChangeLog/8.0>>>
> >          >>      >
> >          >>      > ===
> >          >>      > System emulation on 32-bit x86 and ARM hosts has been
> >         deprecated.
> >          >>     The
> >          >>      > QEMU project no longer considers 32-bit x86 and ARM
> >         support for
> >          >>     system
> >          >>      > emulation to be an effective use of its limited
> >         resources, and thus
> >          >>      > intends to discontinue.
> >          >>      >
> >          >>      >   ==
> >          >>      >
> >          >>      > well, I guess arguing from memory-consuption point on
> 32
> >         bit x86
> >          >>     hosts
> >          >>      > (like my machine where I run 32 bit userspace on 64
> bit
> >         kernel)
> >
> >         All current PCs have multiple gigabytes of RAM, so using a 32-bit
> >         userspace
> >         to save some few bytes sounds weird.
> >
> >
> >     I think difference more like in 20-30% (on disk and in ram), not *few
> >     bytes*.
> >
> >
> > I stand (self) corrected on *on disk* binary size, this parameter tend
> to be
> > ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I do
> not
> > have full identical x64 Slackware setup for measuring memory impact.
> >
> >
> > Still, pushing users into endless hw upgrade is no fun:
> >
> >
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> >
> >
> > note e-waste and energy consumption
>
> Now you're mixing things quite badly. That would be an argument in the
> years
> before 2010 maybe, when not everybody had a 64-bit processor in their PC
> yet, but it's been now more than 12 years that all recent Desktop
> processors

===


Laptops, tablets etc exist.


>
> feature 64-bit mode. So if QEMU stops supporting 32-bit x86 environments,
> this is not forcing you to buy a new hardware, since you're having a
> 64-bit
> hardware already anyway. If someone still has plain 32-bit x86 hardware
> around for their daily use, that's certainly not a piece of hardware you
> want to run QEMU on, since it's older than 12 years already, and thus not
> really strong enough to run a recent emulator in a recent way.
>

Well, current qemu runs quite well, than you very much (modulo all this
twiddling with command line switches). I think very fact it runs well (even
as tcg-only emulator, on integer tasks at least) on 32-bit hosts actually
good, and if 32-bit arm hardware can keep some codeways in working state
for me - even better.

But may be qemu as emulator and qemu as  industrial hypervisor actually
better to live separate lives? I do not know future, just dislike direction
winds are blowing .... since long time, really.



>   Thomas
>
>

[-- Attachment #2: Type: text/html, Size: 7638 bytes --]

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 12.04, Andrew Randrianasulu wrote:

> Also, for CI thing may be lessen compiler optimization levels at least for 
> some runs? And/or tweak ccache compression ....

Please stop blindly making suggestions for our CI if you don't really know 
it (e.g. we don't use ccache). That's really not helpful. Thanks.

  Thomas

Re: dropping 32-bit host support

[Daniel P. Berrangé]

On Thu, Mar 16, 2023 at 02:11:08PM +0300, Andrew Randrianasulu wrote:
> чт, 16 мар. 2023 г., 14:02 Thomas Huth <thuth@redhat.com>:
> 
> > On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> > >
> > >
> > > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <randrianasulu@gmail.com
> > > <mailto:randrianasulu@gmail.com>>:
> > >
> > >
> > >
> > >     чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com
> > >     <mailto:thuth@redhat.com>>:
> > >
> > >         On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> > >          > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> > >          >>
> > >          >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> > >         <philmd@linaro.org <mailto:philmd@linaro.org>
> > >          >> <mailto:philmd@linaro.org <mailto:philmd@linaro.org>>>:
> > >          >>
> > >          >>     Hi Andrew,
> > >          >>
> > >          >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
> > >          >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > >         <https://wiki.qemu.org/ChangeLog/8.0>
> > >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> > >         <https://wiki.qemu.org/ChangeLog/8.0>>
> > >          >>      > <https://wiki.qemu.org/ChangeLog/8.0
> > >         <https://wiki.qemu.org/ChangeLog/8.0>
> > >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> > >         <https://wiki.qemu.org/ChangeLog/8.0>>>
> > >          >>      >
> > >          >>      > ===
> > >          >>      > System emulation on 32-bit x86 and ARM hosts has been
> > >         deprecated.
> > >          >>     The
> > >          >>      > QEMU project no longer considers 32-bit x86 and ARM
> > >         support for
> > >          >>     system
> > >          >>      > emulation to be an effective use of its limited
> > >         resources, and thus
> > >          >>      > intends to discontinue.
> > >          >>      >
> > >          >>      >   ==
> > >          >>      >
> > >          >>      > well, I guess arguing from memory-consuption point on
> > 32
> > >         bit x86
> > >          >>     hosts
> > >          >>      > (like my machine where I run 32 bit userspace on 64
> > bit
> > >         kernel)
> > >
> > >         All current PCs have multiple gigabytes of RAM, so using a 32-bit
> > >         userspace
> > >         to save some few bytes sounds weird.
> > >
> > >
> > >     I think difference more like in 20-30% (on disk and in ram), not *few
> > >     bytes*.
> > >
> > >
> > > I stand (self) corrected on *on disk* binary size, this parameter tend
> > to be
> > > ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I do
> > not
> > > have full identical x64 Slackware setup for measuring memory impact.
> > >
> > >
> > > Still, pushing users into endless hw upgrade is no fun:
> > >
> > >
> > https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> > >
> > >
> > > note e-waste and energy consumption
> >
> > Now you're mixing things quite badly. That would be an argument in the
> > years
> > before 2010 maybe, when not everybody had a 64-bit processor in their PC
> > yet, but it's been now more than 12 years that all recent Desktop
> > processors
> 
> ===
> 
> 
> Laptops, tablets etc exist.
> 
> 
> >
> > feature 64-bit mode. So if QEMU stops supporting 32-bit x86 environments,
> > this is not forcing you to buy a new hardware, since you're having a
> > 64-bit
> > hardware already anyway. If someone still has plain 32-bit x86 hardware
> > around for their daily use, that's certainly not a piece of hardware you
> > want to run QEMU on, since it's older than 12 years already, and thus not
> > really strong enough to run a recent emulator in a recent way.
> >
> 
> Well, current qemu runs quite well, than you very much (modulo all this
> twiddling with command line switches). I think very fact it runs well (even
> as tcg-only emulator, on integer tasks at least) on 32-bit hosts actually
> good, and if 32-bit arm hardware can keep some codeways in working state
> for me - even better.

The problem being debated here is not a technical one, but a question
of resource prioritization.

It is certainly technically possible to keep 32-bit support working
indefinitely and there are certainly people who would benefit from
that, like yourself.

The issue is that it comes at a cost to the QEMU project both in terms
of where our contributors invest their time, and in terms of what we
use our CI resources for. Both maintainer time and hardware resources
are finite quantities.

IOW, if we continue to support 32-bit host, that means that we will
be unable to work on some other feature(s) instead.

The question we're battling with is where to draw the line, so that
we can bring the biggest benefit to QEMU consumers as a whole.

If we keep supporting 32-bit host, that may (hypothetically) benefit
100 users.

If we drop 32-bit host we might be able to develop some new features
that (hypothetically) benefit 5000 new users.

In this illustration, it would make sense to drop 32-bit, because in
aggregate we would loose 100 users, but gain 5000 new users, meaning
a net gain of 4900. Furthermore, since QEMU is open source the users
that we drop support for, do (theoretically at least) still have the
option of continuing to use older releases.

Now those specific numbers were totally invented, and it isn't very
easy to come up with especially accurate numbers. So we have to make
a call based on a combination of factors, our intuition, consideration
of the overall hardware market, feedback from users in response to a
deprecation announcements, and more.

With all those factors together, at this time it is looking likely
that QEMU will be better (on aggregate) if we discontinued support
for 32-bit hosts. We know that is going to upset some users, and
we are sorry for that, but we believe more users will benefit in
the long run by releasing resources to invest in other areas.

The sad reality faced by most open source projects is that plenty
of people are willing to complain when features are dropped or not
accepted, but far far fewer are willing to contribute to the
maintenence effort, to enable the projects to accomplish more
overall.  So the project maintainers are left in an impossible
situation where they unfortunately have to make tough decisions
that leave some people disappointed.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 8741 bytes --]

чт, 16 мар. 2023 г., 15:35 Daniel P. Berrangé <berrange@redhat.com>:

> On Thu, Mar 16, 2023 at 02:11:08PM +0300, Andrew Randrianasulu wrote:
> > чт, 16 мар. 2023 г., 14:02 Thomas Huth <thuth@redhat.com>:
> >
> > > On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> > > >
> > > >
> > > > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <
> randrianasulu@gmail.com
> > > > <mailto:randrianasulu@gmail.com>>:
> > > >
> > > >
> > > >
> > > >     чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com
> > > >     <mailto:thuth@redhat.com>>:
> > > >
> > > >         On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> > > >          > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> > > >          >>
> > > >          >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> > > >         <philmd@linaro.org <mailto:philmd@linaro.org>
> > > >          >> <mailto:philmd@linaro.org <mailto:philmd@linaro.org>>>:
> > > >          >>
> > > >          >>     Hi Andrew,
> > > >          >>
> > > >          >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
> > > >          >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > > >         <https://wiki.qemu.org/ChangeLog/8.0>
> > > >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> > > >         <https://wiki.qemu.org/ChangeLog/8.0>>
> > > >          >>      > <https://wiki.qemu.org/ChangeLog/8.0
> > > >         <https://wiki.qemu.org/ChangeLog/8.0>
> > > >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> > > >         <https://wiki.qemu.org/ChangeLog/8.0>>>
> > > >          >>      >
> > > >          >>      > ===
> > > >          >>      > System emulation on 32-bit x86 and ARM hosts has
> been
> > > >         deprecated.
> > > >          >>     The
> > > >          >>      > QEMU project no longer considers 32-bit x86 and
> ARM
> > > >         support for
> > > >          >>     system
> > > >          >>      > emulation to be an effective use of its limited
> > > >         resources, and thus
> > > >          >>      > intends to discontinue.
> > > >          >>      >
> > > >          >>      >   ==
> > > >          >>      >
> > > >          >>      > well, I guess arguing from memory-consuption
> point on
> > > 32
> > > >         bit x86
> > > >          >>     hosts
> > > >          >>      > (like my machine where I run 32 bit userspace on
> 64
> > > bit
> > > >         kernel)
> > > >
> > > >         All current PCs have multiple gigabytes of RAM, so using a
> 32-bit
> > > >         userspace
> > > >         to save some few bytes sounds weird.
> > > >
> > > >
> > > >     I think difference more like in 20-30% (on disk and in ram), not
> *few
> > > >     bytes*.
> > > >
> > > >
> > > > I stand (self) corrected on *on disk* binary size, this parameter
> tend
> > > to be
> > > > ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I
> do
> > > not
> > > > have full identical x64 Slackware setup for measuring memory impact.
> > > >
> > > >
> > > > Still, pushing users into endless hw upgrade is no fun:
> > > >
> > > >
> > >
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> > > >
> > > >
> > > > note e-waste and energy consumption
> > >
> > > Now you're mixing things quite badly. That would be an argument in the
> > > years
> > > before 2010 maybe, when not everybody had a 64-bit processor in their
> PC
> > > yet, but it's been now more than 12 years that all recent Desktop
> > > processors
> >
> > ===
> >
> >
> > Laptops, tablets etc exist.
> >
> >
> > >
> > > feature 64-bit mode. So if QEMU stops supporting 32-bit x86
> environments,
> > > this is not forcing you to buy a new hardware, since you're having a
> > > 64-bit
> > > hardware already anyway. If someone still has plain 32-bit x86 hardware
> > > around for their daily use, that's certainly not a piece of hardware
> you
> > > want to run QEMU on, since it's older than 12 years already, and thus
> not
> > > really strong enough to run a recent emulator in a recent way.
> > >
> >
> > Well, current qemu runs quite well, than you very much (modulo all this
> > twiddling with command line switches). I think very fact it runs well
> (even
> > as tcg-only emulator, on integer tasks at least) on 32-bit hosts actually
> > good, and if 32-bit arm hardware can keep some codeways in working state
> > for me - even better.
>
> The problem being debated here is not a technical one, but a question
> of resource prioritization.
>
> It is certainly technically possible to keep 32-bit support working
> indefinitely and there are certainly people who would benefit from
> that, like yourself.
>
> The issue is that it comes at a cost to the QEMU project both in terms
> of where our contributors invest their time, and in terms of what we
> use our CI resources for. Both maintainer time and hardware resources
> are finite quantities.
>
> IOW, if we continue to support 32-bit host, that means that we will
> be unable to work on some other feature(s) instead.
>
> The question we're battling with is where to draw the line, so that
> we can bring the biggest benefit to QEMU consumers as a whole.
>
> If we keep supporting 32-bit host, that may (hypothetically) benefit
> 100 users.
>
> If we drop 32-bit host we might be able to develop some new features
> that (hypothetically) benefit 5000 new users.
>
> In this illustration, it would make sense to drop 32-bit, because in
> aggregate we would loose 100 users, but gain 5000 new users, meaning
> a net gain of 4900. Furthermore, since QEMU is open source the users
> that we drop support for, do (theoretically at least) still have the
> option of continuing to use older releases.
>
> Now those specific numbers were totally invented, and it isn't very
> easy to come up with especially accurate numbers. So we have to make
> a call based on a combination of factors, our intuition, consideration
> of the overall hardware market, feedback from users in response to a
> deprecation announcements, and more.
>
> With all those factors together, at this time it is looking likely
> that QEMU will be better (on aggregate) if we discontinued support
> for 32-bit hosts. We know that is going to upset some users, and
> we are sorry for that, but we believe more users will benefit in
> the long run by releasing resources to invest in other areas.
>
> The sad reality faced by most open source projects is that plenty
> of people are willing to complain when features are dropped or not
> accepted, but far far fewer are willing to contribute to the
> maintenence effort, to enable the projects to accomplish more
> overall.  So the project maintainers are left in an impossible
> situation where they unfortunately have to make tough decisions
> that leave some people disappointed.
>


Well, this language about "market" and "investment"  not just figures of
the speech, sadly? Because paid developers work on  areas they paid to
develop, by boss with big bucks.

I think  by now I am in the period when I re-evaluate possibilities and
futures. I was hoping this commitment to fixing 2038 year problem was
indicative of people's investment in longer-term thinking. But what kind of
Linux will we see/use by 2038? One like Android today, full of binary blobs
and false choices, useless without fat data connection and protected very
well from their own users? Who can push back this darker future?

I naturally try to report bugs I encounter and follow up on them. With
slightly less mainstream hardware this means ... more than 5 minutes daily.
Yes, I *do* have fun on my machines, that might involve qemu, mplayer,
86Box and gcc. I hoped my time running git snapshots of many things
actually helped some users beside me.

I think I like to round this with tree more links to qemu-based projects,
because I think they technically interesting and show there is life outside.

https://github.com/xemu-project/xemu
Xbox! including some kind of GPU emulation.

https://github.com/kjliew/qemu-3dfx
Your lovely (possible unsecure) 3dfx!

https://9to5mac.com/2022/12/23/developer-emulates-iphone-os-qemu/

url speaks for itself.

So, there is some positivity, but surrounded by less-than-happy
uncertainty, for me.




> With regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>

[-- Attachment #2: Type: text/html, Size: 14637 bytes --]

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 14.01, Andrew Randrianasulu wrote:
...
> Well, this language about "market" and "investment"  not just figures of the 
> speech, sadly? Because paid developers work on  areas they paid to develop, 
> by boss with big bucks.

Sorry for getting more explicit now, but: Can you please stop making such 
aggressive assertions which are obviously wrong and where you apparently 
have no clue about about?

If you'd followed the QEMU project, you'd know that there are very helpful 
people around, from all kind of companies, Linaro guys who help with 
reviewing and merging non-ARM patches, Red Hatters who help with BSD and 
Haiku patches, etc.

Anyway, if you're not happy with the way the project is evolving, then start 
contributing instead of grumbling.

  Thomas

Re: dropping 32-bit host support

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

On Thu, Mar 16, 2023 at 7:33 AM Thomas Huth <thuth@redhat.com> wrote:

> If you'd followed the QEMU project, you'd know that there are very helpful
> people around, from all kind of companies, Linaro guys who help with
> reviewing and merging non-ARM patches, Red Hatters who help with BSD

and Haiku patches, etc.
>

Without this help, bsd-user would be dead. As it is, it is struggling with
its own
resource issues, but the kind help I've received from the QEMU project has
motivated me to keep going in upstreaming what our fork has, as well as
working to make the code better.

I'll only add that FreeBSD's efforts to improve its CI story was derailed
for two
years by people like this, so it makes me happy to see lines being drawn
in this thread. They aren't unreasonable, and look to me to be in the best
interest of the QEMU project. You can't make everybody happy all the time.
And while it's good to try sometimes, other times it bogs down real efforts
to
make things better. This is one of those times.

Warner

[-- Attachment #2: Type: text/html, Size: 1657 bytes --]

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

чт, 16 мар. 2023 г., 16:32 Thomas Huth <thuth@redhat.com>:

> On 16/03/2023 14.01, Andrew Randrianasulu wrote:
> ...
> > Well, this language about "market" and "investment"  not just figures of
> the
> > speech, sadly? Because paid developers work on  areas they paid to
> develop,
> > by boss with big bucks.
>
> Sorry for getting more explicit now, but: Can you please stop making such
> aggressive assertions which are obviously wrong and where you apparently
> have no clue about about?
>

I usually read much more than I write, thank you very much.



> If you'd followed the QEMU project, you'd know that there are very helpful
> people around, from all kind of companies, Linaro guys who help with
> reviewing and merging non-ARM patches, Red Hatters who help with BSD and
> Haiku patches, etc.
>
> Anyway, if you're not happy with the way the project is evolving, then
> start
> contributing instead of grumbling.
>


Is there any point to contributing to project that happily will told you to
.....go smoke in a corner?

>
>   Thomas
>
>

[-- Attachment #2: Type: text/html, Size: 1936 bytes --]

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

чт, 16 мар. 2023 г., 18:21 Warner Losh <imp@bsdimp.com>:

>
>
> On Thu, Mar 16, 2023 at 7:33 AM Thomas Huth <thuth@redhat.com> wrote:
>
>> If you'd followed the QEMU project, you'd know that there are very
>> helpful
>> people around, from all kind of companies, Linaro guys who help with
>> reviewing and merging non-ARM patches, Red Hatters who help with BSD
>
> and Haiku patches, etc.
>>
>
> Without this help, bsd-user would be dead. As it is, it is struggling with
> its own
> resource issues, but the kind help I've received from the QEMU project has
> motivated me to keep going in upstreaming what our fork has, as well as
> working to make the code better.
>
> I'll only add that FreeBSD's efforts to improve its CI story was derailed
> for two
> years by people like this, so it makes me happy to see lines being drawn
> in this thread.
>

Yeah, this. Just it seems we are ended up on different sides of said line.
But this is ok.


They aren't unreasonable, and look to me to be in the best
> interest of the QEMU project. You can't make everybody happy all the time.
> And while it's good to try sometimes, other times it bogs down real
> efforts to
> make things better. This is one of those times.
>
> Warner
>

[-- Attachment #2: Type: text/html, Size: 2448 bytes --]

Re: dropping 32-bit host support

[Daniel P. Berrangé]

On Thu, Mar 16, 2023 at 04:01:06PM +0300, Andrew Randrianasulu wrote:
> Well, this language about "market" and "investment"  not just figures of
> the speech, sadly? Because paid developers work on  areas they paid to
> develop, by boss with big bucks.

This is FUD.

Many QEMU maintainers are employeed, but that does not mean that their
boss gets to dictate what the QEMU community does. The company has its
priorities but this cannot be forced onto the community. Changes have
to be made through tradeoffs and consensus building across all active
maintainers.

To put it another way, responsible open source maintainers/contributors
wear two hats.

With their corporate hat on they have tasks to work on that are directly
important to their employer in the short term. They can make a case for
why these contributions are beneficial, but there's never a guarantee
the community will agree / accept it.

With their community hat on they look at, and work on, what is important
for the health of the community in general. This can sometimes be contrary
to what the employer would otherwise like to see. Wise companies accept
this tradeoff, because the long term health of the community is ultimately
important to them too.

QEMU is fortunate to have many responsible maintainers who balance the
demands of their employer vs the community on an ongoing basis.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: dropping 32-bit host support

[Andrew Randrianasulu]

[-- Attachment #1: Type: text/plain, Size: 8113 bytes --]

чт, 16 мар. 2023 г., 15:35 Daniel P. Berrangé <berrange@redhat.com>:

> On Thu, Mar 16, 2023 at 02:11:08PM +0300, Andrew Randrianasulu wrote:
> > чт, 16 мар. 2023 г., 14:02 Thomas Huth <thuth@redhat.com>:
> >
> > > On 16/03/2023 11.22, Andrew Randrianasulu wrote:
> > > >
> > > >
> > > > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <
> randrianasulu@gmail.com
> > > > <mailto:randrianasulu@gmail.com>>:
> > > >
> > > >
> > > >
> > > >     чт, 16 мар. 2023 г., 11:31 Thomas Huth <thuth@redhat.com
> > > >     <mailto:thuth@redhat.com>>:
> > > >
> > > >         On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
> > > >          > On 16/3/23 08:17, Andrew Randrianasulu wrote:
> > > >          >>
> > > >          >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
> > > >         <philmd@linaro.org <mailto:philmd@linaro.org>
> > > >          >> <mailto:philmd@linaro.org <mailto:philmd@linaro.org>>>:
> > > >          >>
> > > >          >>     Hi Andrew,
> > > >          >>
> > > >          >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
> > > >          >>      > Looking at https://wiki.qemu.org/ChangeLog/8.0
> > > >         <https://wiki.qemu.org/ChangeLog/8.0>
> > > >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> > > >         <https://wiki.qemu.org/ChangeLog/8.0>>
> > > >          >>      > <https://wiki.qemu.org/ChangeLog/8.0
> > > >         <https://wiki.qemu.org/ChangeLog/8.0>
> > > >          >>     <https://wiki.qemu.org/ChangeLog/8.0
> > > >         <https://wiki.qemu.org/ChangeLog/8.0>>>
> > > >          >>      >
> > > >          >>      > ===
> > > >          >>      > System emulation on 32-bit x86 and ARM hosts has
> been
> > > >         deprecated.
> > > >          >>     The
> > > >          >>      > QEMU project no longer considers 32-bit x86 and
> ARM
> > > >         support for
> > > >          >>     system
> > > >          >>      > emulation to be an effective use of its limited
> > > >         resources, and thus
> > > >          >>      > intends to discontinue.
> > > >          >>      >
> > > >          >>      >   ==
> > > >          >>      >
> > > >          >>      > well, I guess arguing from memory-consuption
> point on
> > > 32
> > > >         bit x86
> > > >          >>     hosts
> > > >          >>      > (like my machine where I run 32 bit userspace on
> 64
> > > bit
> > > >         kernel)
> > > >
> > > >         All current PCs have multiple gigabytes of RAM, so using a
> 32-bit
> > > >         userspace
> > > >         to save some few bytes sounds weird.
> > > >
> > > >
> > > >     I think difference more like in 20-30% (on disk and in ram), not
> *few
> > > >     bytes*.
> > > >
> > > >
> > > > I stand (self) corrected on *on disk* binary size, this parameter
> tend
> > > to be
> > > > ~same between bash / php binaries from Slackware 15.0 i586/x86_64. I
> do
> > > not
> > > > have full identical x64 Slackware setup for measuring memory impact.
> > > >
> > > >
> > > > Still, pushing users into endless hw upgrade is no fun:
> > > >
> > > >
> > >
> https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
> > > >
> > > >
> > > > note e-waste and energy consumption
> > >
> > > Now you're mixing things quite badly. That would be an argument in the
> > > years
> > > before 2010 maybe, when not everybody had a 64-bit processor in their
> PC
> > > yet, but it's been now more than 12 years that all recent Desktop
> > > processors
> >
> > ===
> >
> >
> > Laptops, tablets etc exist.
> >
> >
> > >
> > > feature 64-bit mode. So if QEMU stops supporting 32-bit x86
> environments,
> > > this is not forcing you to buy a new hardware, since you're having a
> > > 64-bit
> > > hardware already anyway. If someone still has plain 32-bit x86 hardware
> > > around for their daily use, that's certainly not a piece of hardware
> you
> > > want to run QEMU on, since it's older than 12 years already, and thus
> not
> > > really strong enough to run a recent emulator in a recent way.
> > >
> >
> > Well, current qemu runs quite well, than you very much (modulo all this
> > twiddling with command line switches). I think very fact it runs well
> (even
> > as tcg-only emulator, on integer tasks at least) on 32-bit hosts actually
> > good, and if 32-bit arm hardware can keep some codeways in working state
> > for me - even better.
>
> The problem being debated here is not a technical one, but a question
> of resource prioritization.
>
> It is certainly technically possible to keep 32-bit support working
> indefinitely and there are certainly people who would benefit from
> that, like yourself.
>
> The issue is that it comes at a cost to the QEMU project both in terms
> of where our contributors invest their time, and in terms of what we
> use our CI resources for. Both maintainer time and hardware resources
> are finite quantities.
>
> IOW, if we continue to support 32-bit host, that means that we will
> be unable to work on some other feature(s) instead.
>
> The question we're battling with is where to draw the line, so that
> we can bring the biggest benefit to QEMU consumers as a whole.
>
> If we keep supporting 32-bit host, that may (hypothetically) benefit
> 100 users.
>
> If we drop 32-bit host we might be able to develop some new features
> that (hypothetically) benefit 5000 new users.
>
> In this illustration, it would make sense to drop 32-bit, because in
> aggregate we would loose 100 users, but gain 5000 new users, meaning
> a net gain of 4900. Furthermore, since QEMU is open source the users
> that we drop support for, do (theoretically at least) still have the
> option of continuing to use older releases.
>
> Now those specific numbers were totally invented, and it isn't very
> easy to come up with especially accurate numbers. So we have to make
> a call based on a combination of factors, our intuition, consideration
> of the overall hardware market, feedback from users in response to a
> deprecation announcements, and more.
>
> With all those factors together, at this time it is looking likely
> that QEMU will be better (on aggregate) if we discontinued support
> for 32-bit hosts. We know that is going to upset some users, and
> we are sorry for that, but we believe more users will benefit in
> the long run by releasing resources to invest in other areas.
>
> The sad reality faced by most open source projects is that plenty
> of people are willing to complain when features are dropped or not
> accepted, but far far fewer are willing to contribute to the
> maintenence effort, to enable the projects to accomplish more
> overall.  So the project maintainers are left in an impossible
> situation where they unfortunately have to make tough decisions
> that leave some people disappointed.
>

To be honest after sleeping over problem I found situation beyond
ridiculous.

IBM is not a charity - they SELL products based on qemu virtualization, for
real, non-trivial money. Same for RedHat. Yet somewhat project running on
servers worldwide has NO RESOURCES and in response jettison minority of
users?

Ever heard word "diversity"? Yes, this is about why small numbers matters,
too! Keeping 32-bit host support  alive at very minimum put some guard
against endless (64bits!) bloating of compiling/linking process.

And seriously, why individual users must pay price? Is IBM on food stamps
suddenly? This is literally their job to provide enough resources for
development process. (not in wasteful manner, tho)

Why not drop 64-bit instead, or at least stall whole pipeline demanding
some improvements?





> With regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>

[-- Attachment #2: Type: text/html, Size: 12670 bytes --]