serenity
serenity copied to clipboard
SerenityOS
Everywhere: Remove i686 support
Closes #15444. Relies on the work of #15465, as well as to support DWARF revision 5 quirks and to ensure UserspaceEmulator is supported on x86-64.
Currently we force when compiling to generate DWARF version 4 for all binaries. We don't have UserspaceEmulator being supported in x86-64 because I need to finish #15465. Regardless, this is pretty much ready for merging as it is right now. I will try to finish the work on supporting UserspaceEmulator, mainly because I don't want it to be sitting in the codebase without usage (there is a risk of code rot too).
Does this affect AK-based userspace apps on different platforms, for instance Ladybird and Jakt? It would be useful to at least keep Ladybird working on i686 platforms as it is quite a light but capable browser. I now checked an I see a bunch of Math functions no longer having optimized versions on i686.
Who is running a 32-bit desktop computer in $CURRENT_YEAR? feels like a best effort thing if anyone with such a computer wants to keep the code working. For math, those optimized versions only mattered when using AK Math for Serenity LibM. Your non-serenity platforms LibM version of those functions is surely better.
Does this affect AK-based userspace apps on different platforms, for instance Ladybird and Jakt? It would be useful to at least keep Ladybird working on i686 platforms as it is quite a light but capable browser. I now checked an I see a bunch of Math functions no longer having optimized versions on i686.
Andrew is right about this, nobody uses an i686 desktop these days in a sanely manner. Even if someone dug up some old dinosaur with Pentium 3 on it (which is probably at least 20 years old?), I don't think they would prefer Ladybird as a browser, to be honest. I am cautious when it comes to speaking for others, but I hardly believe we would want to support and optimize our code for those people too. As for keeping the support, I am not convinced that it's worth it in 2022. If so many people actually care about i686 for this project then one of them should step up and take responsibility to maintain this platform target. For such old machines, our kernel and userland is quite not optimized for, I hardly believe anyone will deliberately use our OS on that setup.
Now, I am not super happy about this decision. However, I see the benefits of the decision. I know some people are disappointed because their hardware will not be supported by our OS anymore. We will basically lose support on the v86 project too, which I personally very admire. In some place, I knew this decision will come sooner or later, and I decided to try do it my way so I can see what are the consequences of this plan and the actual benefits from this. I truly believe that in the long term only good things will come out of this, both in the Kernel side and Userland side too.
Why would someone run 32-bit software in current year? For fun, I say, to see how usable it is, but if the maintenance cost outweighs the fun and support then no problem.
Why would someone run 32-bit software in current year? For fun, I say, to see how usable it is, but if the maintenance cost outweighs the fun and support then no problem.
Exactly for the reason you wrote, it was decided to drop i686 support. By using 32 bit software on a 64-bit capable machine you just limit yourself to a constraint that hardware does not impose - it is you that harm performance and usability of your environment. We don't want to encourage such behavior and although i686 boots a bit faster than x86-64 now, it will change in the future as we keep improving it. In virtualization aspect of the decision - there's basically no justification for keeping i686. It can only be justified for legacy hardware setup.
Maintenance cost at this point is quite high enough to consider this an appropriate measure - we can't introduce kernel fixes to take advantage of the huge virtual memory space in x86-64 without either introducing code duplication or making the code much less readable by using #ifdef soup all over the place. Keeping i686 has great implication on (K)ALSR effectiveness, TmpFS performance and stability issues I try to fix (which is much easier to do with x86-64), and many code paths that are specific to i686 which just add more cost to whoever that needs to maintain it with x86-64 (and in the future, aarch64 as well).
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!
Last thing to do before we can merge this is to ensure that the UserspaceEmulator can be used on x86-64. Then we can get rid of x86-i386 for good :)
Rebased this on latest master. Let's get this in. No need to block it on UserspaceEmulator supporting x86_64, that work will happen when it happens. :)
Rebased this on latest master. Let's get this in. No need to block it on UserspaceEmulator supporting x86_64, that work will happen when it happens. :)
I agree with this. LibX86 still can't parse SSE instructions and this is mandatory for UserspaceEmulator to actually work (run other userland binaries) in long mode. It's completely doable, but it is still a bunch of work. Thank you very much for accepting this, in this way :)
FYI I pushed the branch earlier to fix the CI error, and just pushed again to resolve conflicts against master.
As soon as CI is green let's get this merged @trflynn89 :)
I'll leave the merging of this one up to @awesomekling, just wanted to help push this along :upside_down_face:
Just to get this right. You are building a *unix OS that is focused on the 90s aesthetic, just to remove support for such systems? Do I get you right here?
Exactly for the reason you wrote, it was decided to drop i686 support. By using 32 bit software on a 64-bit capable machine you just limit yourself to a constraint that hardware does not impose - it is you that harm performance and usability of your environment. We don't want to encourage such behavior and although i686 boots a bit faster than x86-64 now, it will change in the future as we keep improving it. In virtualization aspect of the decision - there's basically no justification for keeping i686.
You are quite a funny bunch of people. Ngl. Not even seeing how you are contradicting yourself.
@Citrullin They're not building a 90s OS, but an OS that looks like the 90s. There is a large difference.
Exactly for the reason you wrote, it was decided to drop i686 support. By using 32 bit software on a 64-bit capable machine you just limit yourself to a constraint that hardware does not impose - it is you that harm performance and usability of your environment. We don't want to encourage such behavior and although i686 boots a bit faster than x86-64 now, it will change in the future as we keep improving it. In virtualization aspect of the decision - there's basically no justification for keeping i686.
You are quite a funny bunch of people. Ngl. Not even seeing how you are contradicting yourself.
There's simply one thing you don't understand - we don't live in 90s, but we take ideas that were great from the 90s in the computing space. Also, it is quite rude to come up as a complete stranger on the Internet to this project, telling people they are "funny" just because you don't agree with them. We have (at least I do) some plans on what to do now that i686 is gone, and I will personally dedicate time to work towards implementing those features and optimizations. It is also very rude to think you can tell people what to do, without even giving a little thought on what is the actual maintenance burden (that of course, you are not the one to handle it) of keeping i686 along with 64bit code.