чт, 16 мар. 2023 г., 15:35 Daniel P. Berrangé <berra...@redhat.com>:
> On Thu, Mar 16, 2023 at 02:11:08PM +0300, Andrew Randrianasulu wrote: > > чт, 16 мар. 2023 г., 14:02 Thomas Huth <th...@redhat.com>: > > > > > On 16/03/2023 11.22, Andrew Randrianasulu wrote: > > > > > > > > > > > > чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu < > randrianas...@gmail.com > > > > <mailto:randrianas...@gmail.com>>: > > > > > > > > > > > > > > > > чт, 16 мар. 2023 г., 11:31 Thomas Huth <th...@redhat.com > > > > <mailto:th...@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é > > > > <phi...@linaro.org <mailto:phi...@linaro.org> > > > > >> <mailto:phi...@linaro.org <mailto:phi...@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 :| > >
