Re: [RFC PATCH] docs/about/deprecated: Deprecate 32-bit host systems

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

 



On 30/01/2023 13.43, Daniel P. Berrangé wrote:
On Mon, Jan 30, 2023 at 01:22:22PM +0100, Thomas Huth wrote:
On 30/01/2023 13.01, Daniel P. Berrangé wrote:
On Mon, Jan 30, 2023 at 11:47:02AM +0000, Peter Maydell wrote:
On Mon, 30 Jan 2023 at 11:44, Thomas Huth <thuth@xxxxxxxxxx> wrote:

Testing 32-bit host OS support takes a lot of precious time during the QEMU
contiguous integration tests, and considering that many OS vendors stopped
shipping 32-bit variants of their OS distributions and most hardware from
the past >10 years is capable of 64-bit
...
Do we have a feeling on which aspects of 32-bit cause us the support
burden ? The boring stuff like compiler errors from mismatched integer
sizes is mostly quick & easy to detect simply through a cross compile.

The burden are the CI minutes of the shared CI runners. We've got quite a
bunch of 32-bit jobs in the CI:

- cross-armel-system
- cross-armel-user
- cross-armhf-system
- cross-armhf-user
- cross-i386-system
- cross-i386-user
- cross-i386-tci
- cross-mipsel-system
- cross-mipsel-user
- cross-win32-system

If we could finally drop supporting 32-bit hosts, that would help with our
CI minutes problem quite a lot, I think.

CI is a non-technical constraint, that's more about support level.
>
If we want to save CI minutes, we can declare that some or all of the
32-bit hosts scenarios are now tier 2, rather than tier 1. So the 32-bit
host support still exists, but we're not doing gating CI on every
combination. eg could declare 32-bit for linux-user is tier 1 and fully
tested but 32-bit machine emul is tier 2 and adhoc tested. Or make it
more nuanced per arch target

Well, while the burden currently mostly comes from the CI minutes (since it catches problems immediately, they don't get committed), you would need people's time instead who have to look after the problems once they've been committed to the repository (which will surely happen if we don't check 32-bit host support in the CI anymore).

Who's volunteering in spending his time with analyzing (e.g. bisecting) and fixing those problems? At least I don't.

We only need to deprecate and delete if we have some wins at the code
level that we can't do with while it exists.

We also would have quite some wins at the code level, I think: At least the whole "tcg/arm/" folder would go away, and we could simplify all spots that are using HOST_LONG_BITS in the code base.

 Thomas




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux