docs/about/deprecated.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
We're struggling quite badly with our CI minutes on the shared gitlab runners, so we urgently need to think of ways to cut down our supported build and target environments. qemu-system-i386 and qemu-system-arm are not really required anymore, since nobody uses KVM on the corresponding systems for production anymore, and the -x86_64 and -arch64 variants are a proper superset of those binaries. So it's time to deprecate them and the corresponding 32-bit host environments now. This is a follow-up patch series from the previous discussion here: https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.com/ where people still mentioned that there is still interest in certain support for 32-bit host hardware. But as far as I could see, there is no real need for 32-bit host support for system emulation on x86 and arm anymore, so it should be fine if we drop these host environments now (these are also the two architectures that contribute the most to the long test times in our CI, so we would benefit a lot by dropping those). Thomas Huth (2): docs/about: Deprecate 32-bit x86 hosts and qemu-system-i386 docs/about: Deprecate 32-bit arm hosts and qemu-system-arm docs/about/deprecated.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) -- 2.31.1
On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote: > We're struggling quite badly with our CI minutes on the shared > gitlab runners, so we urgently need to think of ways to cut down > our supported build and target environments. qemu-system-i386 and > qemu-system-arm are not really required anymore, since nobody uses > KVM on the corresponding systems for production anymore, and the > -x86_64 and -arch64 variants are a proper superset of those binaries. > So it's time to deprecate them and the corresponding 32-bit host > environments now. > > This is a follow-up patch series from the previous discussion here: > > https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.com/ > > where people still mentioned that there is still interest in certain > support for 32-bit host hardware. But as far as I could see, there is > no real need for 32-bit host support for system emulation on x86 and > arm anymore, so it should be fine if we drop these host environments > now (these are also the two architectures that contribute the most to > the long test times in our CI, so we would benefit a lot by dropping > those). Your description here is a little ambiguous about what's being proposed. When you say dropping 32-bit host support do you mean just for the system emulator binaries, or for QEMU entirely ? And when the deprecation period is passed, are you proposing to actively prevent 32-bit builds, or merely stopping CI testing and leave 32-bit builds still working if people want them ? 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 :|
On 27/02/2023 19.38, Daniel P. Berrangé wrote: > On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote: >> We're struggling quite badly with our CI minutes on the shared >> gitlab runners, so we urgently need to think of ways to cut down >> our supported build and target environments. qemu-system-i386 and >> qemu-system-arm are not really required anymore, since nobody uses >> KVM on the corresponding systems for production anymore, and the >> -x86_64 and -arch64 variants are a proper superset of those binaries. >> So it's time to deprecate them and the corresponding 32-bit host >> environments now. >> >> This is a follow-up patch series from the previous discussion here: >> >> https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.com/ >> >> where people still mentioned that there is still interest in certain >> support for 32-bit host hardware. But as far as I could see, there is >> no real need for 32-bit host support for system emulation on x86 and >> arm anymore, so it should be fine if we drop these host environments >> now (these are also the two architectures that contribute the most to >> the long test times in our CI, so we would benefit a lot by dropping >> those). > > Your description here is a little ambiguous about what's being > proposed. When you say dropping 32-bit host support do you mean > just for the system emulator binaries, or for QEMU entirely ? Just for system emulation. Some people said that user emulation still might be useful for some 32-bit environments. > And when the deprecation period is passed, are you proposing > to actively prevent 32-bit builds, or merely stopping CI testing > and leave 32-bit builds still working if people want them ? CI is the main pain point, so that's the most important thing. So whether we throw a warning or a hard error while configuring the build, I don't care too much. Thomas
On Tue, Feb 28, 2023 at 08:39:49AM +0100, Thomas Huth wrote: > On 27/02/2023 19.38, Daniel P. Berrangé wrote: > > On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote: > > > We're struggling quite badly with our CI minutes on the shared > > > gitlab runners, so we urgently need to think of ways to cut down > > > our supported build and target environments. qemu-system-i386 and > > > qemu-system-arm are not really required anymore, since nobody uses > > > KVM on the corresponding systems for production anymore, and the > > > -x86_64 and -arch64 variants are a proper superset of those binaries. > > > So it's time to deprecate them and the corresponding 32-bit host > > > environments now. > > > > > > This is a follow-up patch series from the previous discussion here: > > > > > > https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.com/ > > > > > > where people still mentioned that there is still interest in certain > > > support for 32-bit host hardware. But as far as I could see, there is > > > no real need for 32-bit host support for system emulation on x86 and > > > arm anymore, so it should be fine if we drop these host environments > > > now (these are also the two architectures that contribute the most to > > > the long test times in our CI, so we would benefit a lot by dropping > > > those). > > > > Your description here is a little ambiguous about what's being > > proposed. When you say dropping 32-bit host support do you mean > > just for the system emulator binaries, or for QEMU entirely ? > > Just for system emulation. Some people said that user emulation still might > be useful for some 32-bit environments. > > > And when the deprecation period is passed, are you proposing > > to actively prevent 32-bit builds, or merely stopping CI testing > > and leave 32-bit builds still working if people want them ? > > CI is the main pain point, so that's the most important thing. So whether we > throw a warning or a hard error while configuring the build, I don't care > too much. If we're merely wanting to drop CI support, we can do that any time and deprecation is not required/expected. We should only be using deprecation where we're explicitly intending that the code will cease to work. 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 :|
On 28/02/2023 10.01, Daniel P. Berrangé wrote: > On Tue, Feb 28, 2023 at 08:39:49AM +0100, Thomas Huth wrote: >> On 27/02/2023 19.38, Daniel P. Berrangé wrote: >>> On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote: >>>> We're struggling quite badly with our CI minutes on the shared >>>> gitlab runners, so we urgently need to think of ways to cut down >>>> our supported build and target environments. qemu-system-i386 and >>>> qemu-system-arm are not really required anymore, since nobody uses >>>> KVM on the corresponding systems for production anymore, and the >>>> -x86_64 and -arch64 variants are a proper superset of those binaries. >>>> So it's time to deprecate them and the corresponding 32-bit host >>>> environments now. >>>> >>>> This is a follow-up patch series from the previous discussion here: >>>> >>>> https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.com/ >>>> >>>> where people still mentioned that there is still interest in certain >>>> support for 32-bit host hardware. But as far as I could see, there is >>>> no real need for 32-bit host support for system emulation on x86 and >>>> arm anymore, so it should be fine if we drop these host environments >>>> now (these are also the two architectures that contribute the most to >>>> the long test times in our CI, so we would benefit a lot by dropping >>>> those). >>> >>> Your description here is a little ambiguous about what's being >>> proposed. When you say dropping 32-bit host support do you mean >>> just for the system emulator binaries, or for QEMU entirely ? >> >> Just for system emulation. Some people said that user emulation still might >> be useful for some 32-bit environments. >> >>> And when the deprecation period is passed, are you proposing >>> to actively prevent 32-bit builds, or merely stopping CI testing >>> and leave 32-bit builds still working if people want them ? >> >> CI is the main pain point, so that's the most important thing. So whether we >> throw a warning or a hard error while configuring the build, I don't care >> too much. > > If we're merely wanting to drop CI support, we can do that any time and > deprecation is not required/expected. We should only be using deprecation > where we're explicitly intending that the code will cease to work. Well, without CI, I assume that the code will bitrot quite fast (considering that there are continuous improvements to TCG, for example). And who's then still volunteering to fix bugs that have crept in months ago, for a host architecture that nobody really uses anymore? Clearly, 32-bit x86 host is pretty much dead nowadays, especially for programs like QEMU that need beefy host hardware. Why do we still waste our time with this? Thomas
On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote: > Well, without CI, I assume that the code will bitrot quite fast (considering > that there are continuous improvements to TCG, for example). We have lots of hosts which we don't test with CI. They don't bitrot because people do testing before release. This is what RCs are for. We did releases before CI - it is a cost/benefit thing. -- MST
"Michael S. Tsirkin" <mst@redhat.com> writes: > On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote: >> Well, without CI, I assume that the code will bitrot quite fast (considering >> that there are continuous improvements to TCG, for example). > > We have lots of hosts which we don't test with CI. They don't bitrot > because people do testing before release. This is what RCs are for. > We did releases before CI - it is a cost/benefit thing. Dropping 32-bit x86 from CI feels like a no-brainer in the current situation. As to deprecating 32-bit x86: the people by far most qualified to judge the "cost/benefit thing" are the regulars who are bearing the cost, i.e. the people who are actually maintaining it. Their opinion should overrule any "but somebody out there might still want to use it". Maintainers, please state your opinion, if any: aye or nay. Richard tells us "the maint overhead is large." Makes me think he's in favour of dropping 32-bit x86. Richard? Peter seems to be reluctant to drop 32-bit ARM at this point. Peter?
On Wed, Mar 1, 2023, 12:36 AM Markus Armbruster <armbru@redhat.com> wrote: > "Michael S. Tsirkin" <mst@redhat.com> writes: > > > On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote: > >> Well, without CI, I assume that the code will bitrot quite fast > (considering > >> that there are continuous improvements to TCG, for example). > > > > We have lots of hosts which we don't test with CI. They don't bitrot > > because people do testing before release. This is what RCs are for. > > We did releases before CI - it is a cost/benefit thing. > > Dropping 32-bit x86 from CI feels like a no-brainer in the current > situation. > > As to deprecating 32-bit x86: the people by far most qualified to judge > the "cost/benefit thing" are the regulars who are bearing the cost, > i.e. the people who are actually maintaining it. Their opinion should > overrule any "but somebody out there might still want to use it". > > Maintainers, please state your opinion, if any: aye or nay. > > Richard tells us "the maint overhead is large." Makes me think he's in > favour of dropping 32-bit x86. Richard? > > Peter seems to be reluctant to drop 32-bit ARM at this point. Peter? > For FreeBSD systen we have no 32bit arm host users. There may be a few i386 host users left, but they are a tiny sliver of users. The overwhelming bulk of our users for qemu-system- are on x86-64 or aarch64 hosts. For bsd-user, there is no 32 bit host support at all. It was dropped as part of the push to prune old code and upstream. Warner >
On 28/02/2023 22.32, Michael S. Tsirkin wrote: > On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote: >> Well, without CI, I assume that the code will bitrot quite fast (considering >> that there are continuous improvements to TCG, for example). > > We have lots of hosts which we don't test with CI. They don't bitrot > because people do testing before release. Other hosts don't bitrot completely since there are still people out there who are interested in those host systems. But are you aware of anybody who's still actively interested in 32-bit x86 host systems and thus makes sure that QEMU would still work fine there when we publish release candidates? Thomas
On Tue, Feb 28, 2023 at 09:01:46AM +0000, Daniel P. Berrangé wrote: > If we're merely wanting to drop CI support, we can do that any time and > deprecation is not required/expected. We should only be using deprecation > where we're explicitly intending that the code will cease to work. Good point, IMO. -- MST
© 2016 - 2024 Red Hat, Inc.