Лінус Бенедикт Торвальдс — фінсько-американський інженер-програміст, відомий тим, що почав і підтримував розробку ядра Linux,
Останнім часом під час обговорення рішень на процесорах x86, які не підтримуються Інструкція «cmpxchg8b», Лінус Торвальдс заявив, що, можливо, настав час зробити цей оператор обов'язковим для роботи ядра та прибрати підтримку процесорів i486 які не підтримують «cmpxchg8b», а не «намагатися емулювати, як» ця інструкція працює на процесорах, які «більше ніхто не використовує».
Наразі майже всі дистрибутиви Linux, які продовжують підтримувати 86-розрядні системи x32, перейшли на компіляцію ядра з опцією X86_PAE, яка вимагає підтримки "cmpxchg8b".
За Лінусом, з точки зору підтримки в ядрі процесори i486 втратили актуальність, навіть якщо вони все ще зустрічаються в повсякденному житті. У певний момент процесори стають музейними експонатами, і для них цілком реально обійтися «музейними» ядрами.
Варто зазначити, що якщо припинення підтримки класичного i486 триватиме, це не вплине на вбудовані процесори Intel Quark, які, хоча й належать до класу i486, включають додаткові інструкції, типові для покоління Pentium, включаючи «cmpxchg8b».
На додаток до цього згадується, що те ж саме стосується процесорів Vortex86DX. Підтримка процесорів i386 була припинена в ядрі 10 років тому.
Можливо, нам варто сказати, що ми підтримуємо лише x86-32 із «cmpxchg8b» (тобто Pentium і пізніші версії).
Позбудьтеся «емуляції 64-розрядної атоміки за допомогою cli/sti, знаючи, що ніхто не має SMP на цих процесорах», і запровадьте загальне налаштування x86-32 xchg(), використовуючи цей цикл try_cmpxchg64.
Я думаю, що більшість (всі?) дистрибутиви вже ввімкнули X86_PAE, що робить X86_CMPXCHG64 частиною базової вимоги.
Я не переконаний, що сьогодні більшість дистрибутивів навіть розробляють 32-розрядні версії.
...
Ми позбулися підтримки i386 у 2012 році. Можливо, настав час відмовитися від підтримки i486 у 2022 році?
Припинення підтримки i486 може бути важливою віхою, оскільки нещодавно різні дистрибутиви Linux вирішили скасувати підтримку 32-розрядних процесорів, що насправді не мало очікуваних наслідків. Оскільки так, досі є тисячі користувачів, які мають комп’ютери з низьким ресурсом, що зробило Linux чудовим варіантом для продовження їх використання, особливо в багатьох маргінальних регіонах.
І хоча основні дистрибутиви продовжували підтримувати цей тип обладнання, їхні поточні вимоги унеможливлювали його використання. Правда полягає в тому, що все ще є деякі дистрибутиви, які продовжують підтримувати цю архітектуру і, перш за все, які оптимізовані для використання комп’ютерів з низьким ресурсом.
Щодо випадку припинення підтримки, згадується, що користувачі, які мають системи з процесорами i486, зможуть використовувати LTS-версії ядраяка триватиме ще багато років.
З іншого боку, варто також згадати про це розробник драйверів Linux з відкритим кодом для графічного процесора Apple AGX що використовується в чіпах Apple M1 успішно пройшов 99,3% тестів набору dEQP-GLES2, який перевіряє рівень підтримки специфікації OpenGL ES 2. У роботі використовувалися два компоненти: драйвер DRM для ядра Linux, написаний на Rust, і драйвер Mesa, написаний на C.
Розвиток контролерів ускладнюється тим, що Apple M1 використовує власний GPU, розроблений Apple, використовує фірмове програмне забезпечення та використовує досить складні спільні структури даних. Немає технічної документації для GPU, а незалежна розробка драйверів використовує зворотне проектування драйверів macOS.
Контролер з відкритим кодом розроблений для Mesa спочатку тестувався в середовищі macOS поки не буде підготовлено драйвер DRM (Direct Rendering Manager), необхідний для ядра Linux, що дозволило використовувати драйвер, розроблений для Mesa, у Linux.
На додаток до поточного успіху в проходженні тестів dEQP-GLES2, наприкінці вересня драйвер Linux для чіпів Apple M1 досяг рівня, придатного для запуску сеансу GNOME на основі Wayland і запуску гри Neverball і YouTube у браузері Firefox.
В кінці кінців якщо вам цікаво дізнатись більше про це, ви можете перевірити деталі в наступне посилання.