Торвальдс предложил отказаться от поддержки процессоров i486, так как они не умеют работать с инструкцией cmpxchg8b

[lrrr11]

хм, а что там в Cc делает Michael Larabel - тип, который пилит phoronix? Он тоже из этих, мейнтейнеров arch/x86?

[easyman]

Распространяет новости, как минимум :)

Вот пруф: https://www.phoronix.com/news/Intel-i486-Linux-Possible-Drop

[edo1h]

могу предположить, что линус хотел получить максимально возможный отклик вроде «не делайте так, мы выпускаем железки на процессоре xxx, который не поддерживает эту команду, и нам важно иметь свежее ядро», чтобы быть уверенным, что это изменение не преждевременно

[AKudinov]

Del

[funny_falcon]

Думал написать "а те, у кого они еще есть, могут использовать OpenBSD"... Пошёл на сайт OpenBSD, а там "All CPUs compatible with the Intel Pentium or later".

[funny_falcon]

Остаётся NetBSD

[dartraiden]

Те, у кого они есть, в основном используют их как музейные экспонаты. А на таких ПК вполне логично крутить и старые ядра. Если, например, я захочу собрать ретро-ПК, я же не буду туда ставить современную ОС.

[gsaw]

Ну их где то надо брать старые ядра. Хорошо если они где то лежат еще готовые, и не факт, что старое ядро получится собрать из исходников с новым тулчейном.

[edo1h]

тоже мне проблема.
поднял виртуалку с debian 3 (или ещё чем-то подобным по вкусу) и собирай.

[Nikitin_Gs]

Старое ядро можно взять из условной слаки 7 или даже 4. До сих пор люди ими пользуются, как раз на ретро компах

[aim]

5.15 в данном случае "старое ядро".

[emerald_isle]

А исправления найденных уязвимостей?

[kisskin]

если их в музее не подключать к сети, то уязвимости не страшны

[dinisoft]

Ну так и пеньки выкинуть, ведь cmpxchg8b в них глючная. F0 bug.

[edo1h]

Если я правильно помню, баг не в том, что команда как-то не так работает при штатном использовании, а в том, что будучи предварена (ненужным) lock она вешает процессор.

[dinisoft]

Баг в том, что команда предназначена для операций с восемью битами, но только в первых пеньках ей можно передать аргумент в 16/32 бита, тем самым вызвать нештатную ситуацию. Ну а lock, да, он попросту препятствует выводу процессора из состояния неопределённости, т.е. получаем аппаратно повисший проц.

[edo1h]

Если вам важна поддержка этих процессов в свежих ядрах, напишите в список рассылки, поставьте Линуса в cc

[vassabi]

если дело в поддержке только одной инструкции - то ее можно на бинарном уровне сэмулировать (прямо в объектных файлах, перед линковкой).

Я ж не думаю, что кто-то ее вставляет на уровне С\С++ в код ?

[rogoz]

Вопрос не на прикладном уровне, инструкция нужна самому ядру.

[vassabi]

и что - есть какие-то препятствия вместо нее использовать набор других инструкций, получая в итоге такой же результат ?

[rogoz]

Не могу сказать точно, но могу предположить, что нужно вместо просто вставки cmpxchg8b иметь код эмуляции, и главное чтобы кто-то это всё поддерживал ради практически неиспользуемого 486.

[Nikita22007]

По мнению создателя Linux, нужно перестать пытаться эмулировать работу данной инструкции на процессорах, которые уже никто не использует.

Так и происходит

[eurol]

Чем им не угодил процессор-то… Памяти у таких машин все равно мало, 64-битные идентификаторы вряд ли будут полезны, для 32-битных вроде есть команда-аналог.
Про 80386 — тоже грустно, хоть и понятно, что он весьма стар. Ну могли бы для истории оставить ветку…
Ах, да, для современных свистоперделок 4Гб оперативки недостаточно, без PAE уже не обойтись… Так у 80386 и i486 столько не поставишь все равно, разве что на их основе кто сделает «современный» процессор для встраиваемых решений. А зачем процессору с частотой 40Мгц гигабайт оперативки — ума не приложу, как и процессору с частотой 133Мгц, кстати, тоже… И никто не будет использовать их на полную катушку, вряд ли даже GUI станут запускать — не дождешься же.

[edo1h]

а в чём проблема использовать старые ядра?

вот ядро с поддержкой 80386 получало патчи до 2018 года (ещё пять лет после выхода 3.8, в котором поддержку 80386 выпилили):
https://cdn.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.2.102

ядра с поддержкой 80486 также будут получать бэкпорты важных исправлений ещё несколько лет.

[Zhbert]

а в чём проблема использовать старые ядра?

Скорее всего, когда-нибудь может наступить тот момент, когда софт не будет с ним работать. Теоретически. Но можно ведь и не обновлять софт...

[edo1h]

тут всё зависит от упоротости )))

смотрю на wifi-роутер:

Linux Wive-NG-MT 3.4.113.192 #1 SMP Sat Oct 5 17:02:13 +05 2019 mips GNU/Linux

человеку оказалось проще бэкпортировать wireguard и прочие радости в 3.4, чем натягивать sdk от mtk на современные ядра.
а в кинетиках на том же железе 4.9
а в openwrt 5.10 (и куча проблем с wifi, ибо непатченный код от mtk крив, а патчами никто из тех, кто пилит коммерческие прошивки, особо не делится).

и на что влияет версия ядра для конечного пользователя? да ни на что.

[rogoz]

wifi-роутер
на что влияет версия ядра для конечного пользователя? да ни на что.

"Новый ботнет X насчитывает 100500 роутеров".

И чёт я уверен, что " проще бэкпортировать wireguard и прочие радости в 3.4" не значит "бекпортированы все патчи безопасности".

[edo1h]

И чёт я уверен, что " проще бэкпортировать wireguard и прочие радости в 3.4" не значит "бекпортированы все патчи безопасности"

почему нет? если этим занимается команда на full-time.
если говорить именно про wive-ng, то в changelog «kernel» встречается чуть ли не в каждом релизе.

"Новый ботнет X насчитывает 100500 роутеров".

это, всё-таки, больше про userspace, чем про ядро.
уязвимости с rce в ядре бывают, конечно, но обычно или для их эксплуатации нужны какие-то очень экзотические условия, или поднимается шум, так что пропустить такое сложно.

[lain8dono]

Я даже несколько удивлён, что что-то настолько древнее всё ещё поддерживается.