Привет, Хабр! На связи Виктор Сергеев, редактор «МТС Диджитал». Сегодня обсудим «большую чистку» ядра Linux.
Для начала стоит избавиться от поддержки десятков устаревших ARM-процессоров. Многие чипы почти не используются, смысла в их поддержке в ядре Linux все меньше. Но как их убрать, чтобы изменения прошли безболезненно для пользователей? У одного из самых известных контрибьюторов Linux Арндта Бергмана есть план. Подробности — под катом.
Что за план
Бергман предлагает устроить «большую чистку» для ядра Linux и компиляторов из набора GCC (GNU Compiler Collection) — это набор компиляторов для языков программирования в рамках проекта GNU. GCC — открытое ПО. Оно распространяется фондом свободного программного обеспечения на условиях GNU GPL и GNU LGPL.
Если коротко, сначала Бергман хочет убрать поддержку ARMv3 (семейство ARM6) и ARMv4 (ARM 11). Эти чипы появились в конце XX века и давно потеряли актуальность. Некоторые процессоры на базе архитектур ARMv3 и ARMv4 еще изредка применяются, например, в StrongARM и FA526. Но это уже отголоски прошлого.
В случае ARMv4 Бергман считает, что на первом этапе поддержку нужно вырезать из компиляторов и только потом, через несколько лет, — из ядра Linux. Еще от одной архитектуры, ARMv7-M, планируют избавиться в 2027 году. Ее развитие прекращено в 2017-ом.
В 2023 году эксперты проводили анализ ядра и подсчитывали, насколько его можно облегчить, если убрать поддержку устаревших технологий. Выяснилось, что на 154 тыс. строк программного кода. Бергман, к сожалению, аналогичные подсчеты не проводил, но, вероятно, объем «чисток» примерно такой же.
Автор проекта рекомендует не вводить изменения сразу, а избавляться от устаревших технологий планомерно — от совсем не актуальных в настоящее время до иногда используемых.
Какие архитектуры удалят
В плане содержится подробная информация об архитектурах, чипах и расширениях, которые Бергман предлагает удалить:
ARMv3 — ее поддержка уже убрана из GCC 9;
ARMv4 — от архитектуры отказались в Debian 5.0. По плану поддержку ARMv4 прекратят сначала в GCC, а через несколько лет — в ядре;
ARMv4T — сейчас встречается шесть семейств SoC с ядрами ARM720T, ARM920T и ARM922T. Они распространены больше, чем представители вышеупомянутой архитектуры. Бергман предлагает избавиться от поддержки технологии в ядре, но не раньше, чем от ARMv5;
ARMv5 — архитектура применяется примерно на трети всех поддерживаемых в ядре платформ. Казалось бы, все хорошо, но нет: почти все они близки к окончанию жизненного цикла. Из-за отсутствия FPU и атомарных операций сохранять поддержку в Debian, например, все сложнее. Так что, возможно, скоро порт Debian для ARMv5 будет переведен в число неофициальных;
ARMv6 — планируется избавиться только от начальных поколений чипов этой архитектуры, включая ARM1136r0p (NXP i.MX31) и OMAP24xx (Nokia N8xx);
ARMv6K — используется в процессорах ARM1176 (Raspberry Pi 1, AST2500) и ARM1136r1;
ARMv7-M — еще используется в микроконтроллерах на базе Cortex-M3/M4/M7. Это последние из могикан, то есть поддерживаются в ядре чипами без MMU. Бергман предлагает удалить поддержку ARMv7-M в 2027 году, спустя 10 лет после остановки разработки чипов с этой архитектурой;
iWMMXt — в ядре Linux уже нет некоторых чипов на базе этой архитектуры, включая CPU ARMv7 PJ4 (MMP2, Berlin). Поддержка iWMMXt прекращена в Clang, ее предлагают удалить и из GCC;
BE32 (big endian ARMv5) — редкая архитектура, на базе которой построен только SoC Intel IXP4xx. Автор предлагает убрать поддержку технологии как из GCC, так и из ядра;
BE8 (big-endian ARMv7) — во многих драйверах есть проблемы, поэтому ее тоже предлагают вырезать. Тестирование не ведется, да и информации об устройствах, которые работают на базе чипов, нет.
План пока обсуждается, финального решения нет. Автор предлагает не затягивать с ним, а начать работу по очистке ядра Linux уже с версии 6.12. Стабильный дистрибутив запланирован на декабрь 2024 года.
Не только ARM
Разработчики Linux избавляются от наследия прошлого не только в виде прекращения поддержки старых чипов на базе ARM. То же самое они делают и в отношении устаревших x86-процессоров. В самом конце прошлого года из Linux 6.7 удалили код, отвечавший за поддержку микросхем Intel Itanium на базе архитектуры IA-64. Инициатором той чистки был сам Линус Торвальдс. Еще в 2021 году он назвал эти чипы «мертвыми».
А в 2022 году он же предложил удалить и процессоры Intel семейства i486. По словам Торвальдса, технология безнадежно устарела, поэтому из ядра Linux нужно убрать весь связанный с ними код. Ну а поддержку i386 убрали еще в конце 2012, так что i486 продержались достаточно долго.
А что вы думаете о «большой чистке Бергмана» и ее возможных последствиях?
Еще можно почитать:
Комментарии (48)
goldexer
06.08.2024 14:18+4Хлам - долой. Для специализированных случаев есть специализированные редакции и возможность вносить правки. Не верите/не согласны? А ну тогда небыло бы у нас ни Андроида, ни RaspberryPi и проч. Сейчас всё с исключительным уровнем специфичности можно залить в отдельный модуль и расшарить. Только пожалуйста, упаси вас бог превращать это в Виндоус, заплывшей жиром, с огромным полумертвым легаси в каждом дистрибутиве без реального разграничения функционала версий и попытками в новую инфраструктуру на костях старой... Это живёт только на правах монополиста с пренебрежением ущерба репутации. Линукс же изначально был... ну вы и сами знаете
bodyawm
06.08.2024 14:18+11Заслуженно поставил диз. Много усилий тратится на поддержку SoC мейнлайном - и теперь все выбросить в отдельную ветку? Ну уж нет.
Приведите пример откровенного легаси в винде, не вынесенное в отдельный компонент
goldexer
06.08.2024 14:18+5Да хоть десять дизов. Андроид, он на базе чего? На скольких миллионах устройств работает и что происходит с устройством, когда производитель «прекращает поддержку»?
Сколько производители и энтузиасты перепиливают вдоль и поперёк, пересобирая, адаптируя? Им кто-то что-то запрещает что-ли? В отличие от...
А что касается винды, то:
В системых библиотеках тонны кода для работы с устаревшими компонентами. Даже просто залезть в WinAPI, чтобы почитать, там... Что-то там про старые порты ввода... Эмулировать тоже не будем, пусть люди сами пишут драйвера. Совместимость, спустя три десятилетия, в самой передовой версии? Когда новейшие обновления ломают новейшую же систему? Нет, это всё надо тащить! А вдруг кому-то пригодится. Только истории по типу TPM 2.0 мы будем исполнять, потому железо выкидывайте, а вот софт ни-ни. Что-то там про разные версии систем для разных поколений железа? Серверная? О чём это вы(сарказм)?. Аэропорты, вокзалы, до сих пор работают в некоторых странах на 3.1 или 95? А спросите их, почему не обновляются, там же обратная совместимость? Сбой вот недавно дал кое-какие ответы...
Призванная когда-то совершить революцию, .NET-платформа, повисла сверху, тихо став частью. Вы хоть примерно представляете, сколько в процессе прогресса версий файлов сборок выблевалось на жесткий диск? Сколько пользователей заставляли устанавливать и работать вторую с третьей и четвертной и... и это с их промежуточными версиями, сборки которых никуда не девались после обновления программ! Одна только .NET-платформа сама себя превратила в свалку легаси!
Сколько вы готовы выделить на диске, для дубликатов файлов для безопасности, которые будет хранить винда? Да, это не легаси, но это входит в тему жирноты! Не переживайте, когда придёт время, большинству пользователей они не помогут, эти фалы. Итак, в своё время 80Гб системная папка свежей установленной системы на 120Гб винте, эт ж норма, чё... Да, не у всех, но чем рядовой обыватель виноват, купив лицензию? Почему вообще эта проблема существовала
Предыдущий пункт, но syswow64, 32х битки vs 64x и это тоже надо дублировать и куда-то девать.
Даже на абсолютно чистой системе люди жалуются, открыв журнал ошибок... почему вообще такая проблема должна существовать и почему они не решают это уже много версий подряд.
Две панели управления в 11й, два меню по правому клику... а вот для защитников легаси, некоторые ставшие привычными вещи, надо убирать, потом добавлять, потом снова убирать... Это же так должно работать? Это может бесить, может не нравится, но жаловаться MS бесполезно, решать самому - вмешиваться в работу системы, весомых альтернатив, для варианта «не нравится - чемодан, вокзал», просто нет.
Есть ещё пункты, но мы раздуем полемику, а мне реально лень
Сколько стоит загрузить GDI библиотеку (не GDI+)? Сколько программ её реально сейчас используют? Что слышно с mswinsck.ocx, dx8vb.dll, технология OLE и все-все-все? Каждый день поключаются устройства USB 1.0. Там Xamarin устарел кстати. Что там с поддержкой APK? Куда девается это всё на домашнем ПК? Винда на ARM переехала кстати.
Прогресс не стоит на месте, это понятно и очевидно. MS пытается откусывать то тут, то там. Но экономит даже на тестерах! И всё болото оседает мёртвым илом.
Ну не надо мне заливать, что та версия винды, которая ставится на мой ПК, максимально прилизанная от прошлой и адаптируется под железо и ставящийся софт на лету
bodyawm
06.08.2024 14:18+35Лол, я просил привести core-элемент винды, вы накатали простыню текста о её компонентах. Но ок, давайте по порядку:
Да хоть десять дизов. Андроид, он на базе чего? На скольких миллионах устройств работает и что происходит с устройством, когда производитель «прекращает поддержку»?
Сколько производители и энтузиасты перепиливают вдоль и поперёк, пересобирая, адаптируя? Им кто-то что-то запрещает что-ли? В отличие от...
Причём тут вообще Android? Что там творится в юзерспейсе ведра - дело гугла и они хорошо, к слову, держат совместимость между версиями - софт для 1.0 вполне запустится на 12.
Кастомы это замечательно, согласен. Но они здесь вообще не причем, поскольку обычно не трогают ни вендорские драйвера, ни как-то глобально ядро в целом (в основном, меняются планировщики, конфигурация кэшей и т.п.) и я в целом говорил о том, что вложено много усилий принести многие SoC в мейнлайн (например, совсем недавно добавили более чем актуальный AllWinner F1C100S/F1C200S и V3S, которые под капотом ARMv5 - а вот их уже хотят выбросить, хотя чипсет вышел несколько лет назад и используется в куче одноплатников и разных устройств).
Даже просто залезть в WinAPI, чтобы почитать, там... Что-то там про старые порты ввода...
А, ну тоесть если вы не разбираетесь, значит они не нужны?) Ничего что код для работы, например, с COM-портами успешно абстрагирует не только COM-контроллер в IBM-PC, но и UART-контроллеры в ARM-машинах, а также USB CDC устройства как минимум? Ок, LPT древний? Давно уже нет таких принтеров и сканеров? Давайте вспомним, что LPT - это почти полноценная гребенка GPIO и параллельная шина, чем пользовались в embedded оборудовании и пользуются скорее всего и сейчас, хотя в винде и есть нормальный интерфейс для GPIO!
Идём дальше: такие древние и ненужные шины PCI, AGP... а потом внезапно узнаем, что в софтовой части PCI, AGP и PCI-E очень похожи и реализация поддержки PCI-E тянет автоматически поддержку PCI и AGP. Ой как неудобно! Ну а ISA думаю уже давно убрали, там действительно интерфейс иной был с дерганьем отдельных аппаратных прерываний.
Эмулировать тоже не будем, пусть люди сами пишут драйвера
Эмулировать что? Над портами есть абстракции - в юзерспейсе любой последовательный интерфейс, хоть CDC, хоть UART выглядит как COM-порт и управляется как COM-порт. Это - правильно решение, в Linux точно также, как и в Darwin. Давайте вы сначала напишите хоть один драйвер используя DDK (он не идеален, но не настолько говно как кажется), потом уже будете говорить что там плохо, а что нет?)
Совместимость, спустя три десятилетия, в самой передовой версии
Не вижу проблемы. В винде она реализована правильно - например я писал недавно демку на D3D6 (GAPI вышедшее в 1998), винда попросила установить компонент D3D6 отдельно с какого-то своего репозитория и все - это не часть самой системы.
Когда новейшие обновления ломают новейшую же систему
Это единичные случаи. За всеми машинами не уследишь. И сейчас не времена XP с ASR, винда вполне может в автоматическом режиме отключить загрузку "кривых" драйверов. Раньше краш видеоподсистемы вешал ОС, сейчас крашит WDM и все D3D приложения (OpenGL сами восстанавливали стейт) и все работает норм.
Вы хоть примерно представляете, сколько в процессе прогресса версий файлов сборок выблевалось на жесткий диск? Сколько пользователей заставляли устанавливать и работать вторую с третьей и четвертной и... и это с их промежуточными версиями, сборки которых никуда не девались после обновления программ! Одна только .NET-платформа сама себя превратила в свалку легаси!
У дотнета есть пару причин для такого деления на разные модули:
Во первых, поведение некоторых методов менялось от версии к версии. Это лучше чем if(target == "2.0") else. Во вторых, в дотнете значительно менялся механизм проверки подписей у сборок и вообще концепции безопасной среды - это ближе к дотнету на серверсайде, я об этом мало могу рассказать, но когда пилил интероп на WP8 и ПК - столкнулся с этим.
Ну и дотнет это сторонний компонент как минимум.
Сколько вы готовы выделить на диске, для дубликатов файлов для безопасности
Я вам про одно, вы мне про другое)
Предыдущий пункт, но syswow64, 32х битки vs 64x и это тоже надо дублировать и куда-то девать.
А вот чтобы понимать зачем нужны дубли dll'ок в 64х-битном окружении - нужно иметь хоть какой-то опыт нативного программирования под x64. Просто так подгрузить x86 либу не выйдет - будет бардак и с доступом к регистрам, и организации памяти и банально с базовыми типами. Тоже самое и в Linux, где требуется ставить отдельный libc и точно такой-же слой совместимости для поддержки x86 платформ :)
В случае с ARM насколько мне известно есть возможность поставить даже ARMv5 софт с SoftVFP ABI - но тоже нужно ставить небольшой слой совместимости.
а мне реально лень
И по сути, кроме .NET - всё личные догадки человека, который наверняка не написал ни одного драйвера и не полностью понимает как работает юзерспейс слой винды под капотом. Я просил перечислить Core-функционал винды, а не её отделяемые компоненты - вы же привели в основном именно отдельные компоненты.
Сколько стоит загрузить GDI библиотеку (не GDI+)? Сколько программ её реально сейчас используют
Внезапно, сам GDI+ рисует на GDI-контекстах, но для понимания этого нужно иметь опыт работы с этими подсистемами :) Использует очень много, весь виджет тулкит винды на ней подвязан, в том числе и оконная подсистема (правда сам GDI уже давно подвязан на DXGI и D3D). Какие программы реально сейчас используют? Ну, внезапно не весь софт повально на Electron'е и Qt пилится, всё ещё в ходу VCL, WinForms, wxWidgets.
Что слышно с mswinsck.ocx, dx8vb.dll
VB6 давно неактуален, да. А ActiveX местами иногда используется. Мозилла даже утащила концепцию COM в свои проекты.
Короче пока что я от вас вижу лишь предположения и догадки как пользователя, который считает что если ему не нужен GDI или абстракция от COM-портов - значит не нужен никому (в т.ч и софту, которым он пользуется каждый день) и никаких машин (в т.ч промышленных) кроме его ПК для игр и программирования на жабоскриптике - не существует. Как будет что-то по делу - пишите, опровергну, или если напишите по факту - соглашусь.
Pubert
06.08.2024 14:18+1Вставлю свои 5 копеек: некорректно просить привести примеры core-элементов гибридной системы в сравнении с монолитным ядром linux. Я считаю, что аргументы, связанные с .NET, следует засчитать. Так или иначе, без этого НЕ core-элемента винда из себя мало что представляет, а вина за разведённый зоопарк актуальных версий лежит именно на MS. То, что dotnet сторонний компонент, также некорректно. Это компонент, который в большинстве простых пользовательских сценариев обязателен к установке, и, опять же, его разработчиком является сама MS
daggert
06.08.2024 14:18+8Тогда обсуждая линукс надо в эту копилку добавлять Qt, gnome и т.п.? Ведь на них построено огромное количество софта и они обязательны к установке в большинстве сценариев. Еще питон, наверное.
Vladekk
06.08.2024 14:18+3А мне кажется, что претензии к дотнет надуманы. Сейчас вообще можно с собой взять "свой" дотнет, упакованный рядом со своей программой, и это как раз неплохой путь.
Так точно знаешь, что всё будет работать. Диски очень дёшевы, а надёжность, стабильность и то, что программу можно просто скопировать, и она заработает, выгоднее, чем экономия несчастных 100-200 МБ.
Одна проблема - обновления безопасности.
bodyawm
06.08.2024 14:18Человек именно про фреймворк говорил, у него действительно есть с этим, в некоторой степени, проблема, но не критичная.
0xdead926e
06.08.2024 14:18+3Ну а ISA думаю уже давно убрали
не убрали, но обновили. сейчас она называется LPC и к ней, например, подключен мультяк. логически то же самое, конвертится друг в друга без проблем. и ио-порты все еще используются. да и прерывания все еще можно дернуть, даже из pcie.
bodyawm
06.08.2024 14:18Да, спасибо за подсказку! LPC в физической части значительно отличается от ISA, но софтово ситуация как с PCI/AGP/PCI-E.
goldexer
06.08.2024 14:18Ну вы же сами и расписали, что все это легаси. Это неважно, как именно над системами бородатых годов наваяли абстракции. Важно, что все это тянется, дублируется, латается - но ничего не приведено в порядок в достаточной степени или переписано с нуля. И производители железа так же вынуждены использовать старые шины десятилетиями. Так или иначе, это либо пересажено на другие рельсы, чтобы работало аппаратное ускорение, но при этом сохранен и старый вариант, либо продублировано 32+64, а еще, хоть это уже вопрос жирноты, бэкапится в системную папку. И это, как выше сказали, не опенсорс система, а ещё они фактически монополисты. А ещё таскать с собой кучу библиотек и дублировать их версионированием - такая себе идея. Диски может и дешёвые, но не должен, условный, Вайбер, занимать больше, чем профессиональный пакет моделирования не самой современной редакции. Это тоже куча хлама, который совершенно не нужен. Хорошо, а интерфейс зачем новый поверх старого? Чтобы пользователями было легче привыкать? Во-первых всё-равно часто надо переключать на старый вариант, а это время, это бесит, во-вторых майкам на наше привыкать всегда было по-барабану.
Ещё раз моя основная мысль: сама по себе добрая часть винды, это легаси и костыли, которые тянутся десятилетиями, обрастая новыми решениями, которые так же раздувают размер. Нам каждый раз обещают что-то совершенно новое, а продают все так же старое
bodyawm
06.08.2024 14:18Причем тут ос и сторонний софт!? Какие старые шины!? Вы понимаете, что тот же COM и UART софтварно один и тот же протокол и ничуть не менялся за 50 лет потому что это не нужно, он уже идеален для своих задач? Тоже самое о софтовом ISA: это просто маппинг внешних устройств к инструкциям in/out и механизм обработки прерываний.
Учите матчасть, потом приходите спорить.
SwingoPingo
06.08.2024 14:18Все это зачастую "надо тащить" если ты хочешь продаваться и работать в гос. структурах, где ты обязан соответствовать распоряжению, написанному в 8*х годах и до сих пор актуальному. Это еще с win95 повелось все эти богом забытые порты и ущербные архитектурные решения, которые микрософт с упорством вставлял в каждый новый релиз.
Astroscope
06.08.2024 14:18+2все эти богом забытые порты
Какие именно? COM, LPT? Я, конечно, и близко не предполагаю нижеследующее экстраполировать на всех, но я этими портами пользуюсь приблизительно ежедневно, безотносительно того, существуют они в виде аппаратных разъемов на материнской плате, в виде аппаратной эмуляции (обычно USB-COM) или в виде чисто софтовой эмуляции (виртуальные кабели), поэтому меня ваш комментарий удивил, но возможно я просто неправильно вас понял.
ImagineTables
06.08.2024 14:18+1Совместимость, спустя три десятилетия, в самой передовой версии? Когда новейшие обновления ломают новейшую же систему? Нет, это всё надо тащить! А вдруг кому-то пригодится.
А вы думаете, мы ставим Windows, чтобы полюбоваться на его баги? Если бы мы не пользовались старыми WinAPI-программами, а только современными бесхендловыми, мы бы их и запускали из-под Линукса.
Вряд ли только всё это имеет отношение к поддержке ARM'ов в ядре Линукса.
Сколько стоит загрузить GDI библиотеку (не GDI+)? Сколько программ её реально сейчас используют? Что слышно с mswinsck.ocx, dx8vb.dll, технология OLE и все-все-все?
Это шутка?
saboteur_kiev
06.08.2024 14:18+7Приведите пример откровенного легаси в винде, не вынесенное в отдельный компонент
Некорректный пример. Винда не опен-сорс система, вы не можете взять и выкинуть ненужные модули из проприетарной винды или добавить их самостоятельно, не нарушая лицензию.
А легаси в винде огромное количество.
kenomimi
06.08.2024 14:18+6Давно пора. История в гите есть, релизы в архивах есть. Кому надо поддержку железа времен палеолита - тот знает, где брать нужный код.
ARMv7-M — еще используется в микроконтроллерах на базе Cortex-M3/M4/M7.
Оно есть в мейнлайне? Не знал. Был вроде форк ucLinux для поддержки жирных микроконтроллеров, но о нем уже давно ничего не слышно...
le2
06.08.2024 14:18+10Поработал с исходниками десятка Андроид-сборок для телефонов от разных поставщиков. Секретные сведения - то что у вас в кармане даже на Андроид 14, вполне может быть на ядре Linux 4.14 или 4.19, то есть на ядрах семилетней давности.
Мораль - промышленность слабо волнует что там затеяли разработчики Linux.
Ядро Linux стремительно переписывают. API меняется. Поддерживать GPU, NPU, модем и прочее очень больно. Мало кому будет дешево держать ядро в актуальном состоянии.
MrPlap
06.08.2024 14:18+1Андроид 14, вполне может быть на ядре Linux 4.14
На всякий случай проверил. Android 14, ядро 5.10.198
opusmode
06.08.2024 14:18На самом деле практика показала, что:
1. Избавляться от старья нужно и полезноДелается это, увы, только волевым решением.
Мы же прекрасно помним, каким был переход с 32 бит на 64? Как там всё решилось? ДА вот когда все разом рубанули, тогда и перешли. А ведь нытья столько было..
Это же касается кучи инструкций в проце и кучи древних технологий. Как решили? ДА тоже взяли и рубанули.
Вот и тут вполне себе пора. Нет, ну в смысле я всё могу понять, но i486? Реально? Ему точно нужно последнее ядро?
bodyawm
06.08.2024 14:18+5Это же касается кучи инструкций в проце и кучи древних технологий. Как решили? ДА тоже взяли и рубанули.
Да кто рубанул то?) Нормальный софт всегда проверяет наличие тех или иных SIMD и имеет откат на решение без векторизации.
Andrusha
06.08.2024 14:18+2Может и не нужно, но клоны 486-го и 386-го вполне себе выпускаются до сих пор.
bodyawm
06.08.2024 14:18486'ые в свое время были неплохими "микроконтроллерами" и использовались не только в ПК, но и многих крутых девайсах!
AllexIn
06.08.2024 14:18+5Когда рубанули(выпустили итаниумы) - как раз нкто не перешел, а покрутили у виска.
А вот когда AMD выкатили своё решение, которое как раз ничего не рубило, а давало возможность работать и как 64 и как 32 - тогда все потихоньку переползли.bodyawm
06.08.2024 14:18Комментатор выше про опыт Apple, но у яблочников своя атмосфера. С открытыми системами такое не проканает
vaslobas
06.08.2024 14:18У яблочников при каждом переходе было все норм.
Переходы:
PPC->x86. Был транслятор Roseta. Работал очень достойно, я даже играл в игра на x86, которые были под ppc.
x86-32 -> x86-64. Сколько-то лет поддерживался запуск х32 приложений, хотя уже не было новых устройств не с х86-64 процессорами. Переход был очень мягкий и почти незаметный. Я столкнулся только с тем, что World of Warcraft ванильный 32 битный и его никак не запустить. Но клиенту на тот момент было больше 10 лет, новые версии были уже 64 битные.
x86 -> arm. Здесь опять сделали транслятор roseta 2. Работает он отлично, для меня переход был бесшовный. Единственный затык у меня был с докер образами, которые были собраны по х86. Тут просадка была существенна. Ну, и линукс х86, чтобы запустить нужно поднимать qemu. Скорости там ужасные.
QuarkDoe
06.08.2024 14:18+2Вполне нормально чистить код от неиспользуемого легаси, т.к. его поддержка тоже тратит время.
А для тех кому надо, старые версии ядра ни куда не делись.
0xC0CAC01A
06.08.2024 14:18Дык, они же со временем будут с кучей незакрытых дыр по безопасности.
Auerd
06.08.2024 14:18Дык, старое железо тоже с дырами по безопасностям будет. Эту проблему уже никаким софтом не решишь
Panzerschrek
06.08.2024 14:18Хорошее начинание - удалить хлам. Но как-то уж больно консервативно и с осторожностью к этому подходят, можно было бы жёстче это делать - удалять поддержку не только совсем уж древних процессоров, но и просто старых. А кому эта поддержка нужна - может всегда воспользоваться более старой версией ядра.
Inan_Morgan_Sebynu
06.08.2024 14:18+1Из перечисленного слегка переживаю только за малинку первой версии. Но думаю те энтузиасты, которые до сих пор используют ее в своих проектах - давно уже выкачали нужные сборки linux, и в обновлениях не особо нуждаются.
К тому же, ядро linux - открыто. И если кому надо будет добавить поддержку старых процессоров с новыми API - покопается, разберется
Grikhan
06.08.2024 14:18Это целиком вопрос экономики. Конечно, хотелось бы иметь не только поддержку в новом ядре своей старой "ламповой" архитектуры ЦПУ, но и вообще поддержку старого ядра до бесконечности. Для успешной эволюции от рудиментов надо когда-то избавляться.
Maccimo
06.08.2024 14:18+5Из Linux уберут поддержку десятков ARM-чипов. Что происходит?
Что происходит?
Вы родили желтушный заголовок, вот что происходит. Это примерно как на оживлённой улице харкнуть на тротуар.Сегодня обсудим «большую чистку» ядра Linux.
Ну и где это «обсудим»?
Вы просто перепечатали информацию из других источников, попутно привнеся свои собственные ошибки, но не привнеся новых мыслей.То же самое они делают и в отношении устаревших x86-процессоров. В самом конце прошлого года из Linux 6.7 удалили код, отвечавший за поддержку микросхем Intel Itanium на базе архитектуры IA-64.
Itanium никогда не был x86-процессором, это совершенно иные архитектура и набор команд. Эмуляция x86 на нём была не особо быстрой и это вышло ему боком.
А что вы думаете о «большой чистке Бергмана» и ее возможных последствиях?
Думаю, что подобный стиль изложения неуместен на Хабрахабре. Пишите нормально, вы же «редактор», вам за это зряплату платят.
ahdenchik
06.08.2024 14:18+1В случае ARMv4 Бергман считает, что на первом этапе поддержку нужно вырезать из компиляторов и только потом, через несколько лет, — из ядра Linux. Еще от одной архитектуры, ARMv7-M, планируют избавиться в 2027 году. Ее развитие прекращено в 2017-ом
Если они начнут удаление ARMv7-M с компиляторов это будет катастрофа
Это ядра одних из самых популярных контроллеров. А уж по соотношению цена/производительность они, скорее всего, вообще топовые
NeoCode
Не одобряю такого. ИМХО, в идеале вся поддержка старых чипов должна заключаться в принципе "работает - не трогай". Ведь чипы не меняются? Значит и поддерживать ничего не надо.
А тот факт что поддерживать все-же надо из-за изменений в самом ядре и компиляторе, лишь указывает на несовершенство языка программирования, на то что язык Си не обеспечивает 100-процентную инкапсуляцию различных компонентов и их независимость друг от друга.
gudvinr
Так в том и дело, что НЕ работает.
Ядро постоянно развивается, включая API, которые используются легаси кодом. Изменения API могут поломать код поддержки старых архитектур.
Поэтому кто-то должен постоянно их проверять с новыми ядрами. А кто будет их проверять, если никто ими не пользуется?
Получается, что в ядре находится код с непонятным статусом, но который надо поддерживать, на который надо ориентироваться при совершении изменений. Хотите, чтобы не удаляли - поддерживайте и проверяйте сами. Только так.
Более того, даже с новым ядром далеко не факт, что ПО поверх ядра запустится т.к. в старых процессорах могут отсутствовать инструкции, необходимые новым программам - SIMD и пр.
Поэтому скорее всего на такой старой системе проще и удобнее будет работать со старым ядром и старым ПО.
Nansch
А почему эти чипы всё ещё в ядре, а не в модулях?
NickDoom
А разве собранное ядро вообще несёт какой-то бинарный код, который принципиально не может исполняться здесь и сейчас? Как я понял, речь идёт о сырцах, которые подключаются под тот или иной таргет (целевую архитектуру компиляции).
Так что с точки зрения структуры сырцов они уже «в модулях» :) просто если оно слишком распухает, начинается постоянное «ойнесобирается», ну а при необходимости можно что-то в более-менее частном порядке обратно втащить, я думаю… но, правда, придётся продраться через все «ойнесобирается», которые накопились :)
А бинарные модули по понятной причине в тех же машкодах, что и ядро, так что эти (буквальные) модули нам не помогут %)
gudvinr
А какая разница? Если их никто не поддерживает, они не будут работать ни в ядре, ни out-of-tree
Тем более, что это поддержка целевой архитектуры, как её модулем собрать, и главное - зачем? У вас ядро для архитектуры Х будет в таком случае собрано без поддержки архитектуры Х
equeim
С точки зрения разработчиков ядра все что не находится в официальном гит репозитории ядра не существует. Перенос в out of tree модуль для них это тоже самое что и удаление. В ядре нет - значит не поддерживается.
Volodichev
Не вопрос. Работает - не трогай. Просто не обновляй ядро на дышащем на ладан железе.
yri066
Дело не только в возрасте, но в том что новом коде начинает требоваться поддержка новых инструкций, а также люди обновляют железо и количество людей использующие устаревшее оборудование стремится к 0, в таком случае если никто не использует оборудование на старой архитектуре, то ее поддержку нужно убрать, чтобы не тянуть дальше мертвую архитектуру.
dartraiden
Неизвестно, работает ли. Для многих чипов не производится тестирование из-за отсутствия у мейнтейнера соответствующего железа.
А что-то вообще заведомо сломано, потому что в других подсистемах ядра произошли существенные изменения, а код, отвечающий за поддержку этих чипов, никто не взялся адаптировать. Заставить кого-то это сделать принудительно вы не можете.