Линус Торвальдс категорически высказался против предлагаемой поддержки режима big‑endian для архитектуры RISC‑V в ядре Linux. Всё началось с вопроса в рассылке о том, смогут ли патчи для RISC‑V BE попасть в текущий цикл разработки ядра:

О господи. Кто‑то всерьёз занимается поддержкой BE в 2025 году?

ЗАЧЕМ?

Серьёзно, это звучит просто ТУПО. Есть какая‑то реальная причина для этого, или это снова история в стиле «RISC‑V используется в академических курсах по проектированию, и люди хотят заниматься порядком байтов из академического интереса»?

Потому что я был бы более чем счастлив просто провести черту и сказать: 'Новые проблемы с порядком байтов — это чья‑то ЧУЖАЯ проблема', и сказать людям перестать валять дурака.

Давайте не будем усложнять вещи без веской причины. И у нас НЕТ причин добавлять новый порядок байтов.

RISC‑V и так уже достаточно запутанная архитектура с миллионами глупых проблем в конфигурации. Не делайте всё ещё хуже.

Лучше посоветуйте этим людям сходить к психотерапевту. Это будет ГОРАЗДО продуктивнее.

Аргументы Линуса выглядят вполне обоснованными.

Затем Линус погуглил информацию и ещё больше разошёлся:

Окей, я только что погуглил это, и я принял решение:

МЫ НЕ БУДЕМ ПРЕВЕНТИВНО ПОДДЕРЖИВАТЬ BIG‑ENDIAN НА RISC‑V.

Задокументированное 'обоснование' этого безумия слишком глупо для слов, но поскольку riscv.org всё же выразил это словами, я просто процитирую эти слова здесь:

«Всё ещё существуют приложения, где важен способ хранения данных, например протоколы, передающие данные через Интернет с полями big‑endian. Поэтому когда little‑endian системе нужно прочитать или изменить сетевой пакет, ей приходится менять big‑endian значения на little‑endian и обратно — процесс, который может занять до 10–20 инструкций на платформе RISC‑V без расширения Zbb»

Другими словами, это предполагает, что RISC‑V добавит режим big‑endian из‑за

(a) интернет‑протоколов — где перестановка байтов не является проблемой

(b) использования «некоторых реализаций RISC‑V, которы не поддерживают существующее расширение Zbb» в качестве оправдания.

Это просто безумие. Во‑первых, даже если бы перестановка байтов была реальными затратной для сетей — а это не так, ведь реальные затраты обычно связаны с подсистемами памяти — просто реализуйте чёртово расширение Zbb.

Не говорите «мы слишком некомпетентны, чтобы реализовать Zbb, поэтому мы просим чтобы ВСЕ ОСТАЛЬНЫЕ почувствовали боль от гораздо худшего решения и ещё больше фрагментируем RISC‑V».

Я надеюсь, что это какая‑то первоапрельская шутка, но эта страница датирована «10 марта 2025 года». Близко, но недостаточно близко.

Это тот тип глупых вещей, который просто выставляют RISC‑V в плохом свете.

Бен[автор коммита] — я боюсь, что на этой странице есть «доп материалы», указывающие на codethink.

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

Главное ядро для основной разработки. Не для случайных экспериментов, которые делают мир хуже.

И да, мы open source, и это означает, что более чем приветствуется попытаться доказать, что я неправ.

Если окажется, что BE RISC‑V станет реальной вещью, которая релевантна и действительно найдёт место в экосистеме RISC‑V, тогда конечно мы должны поддерживать это в этот момент в главном ядре.

Но я действительно думаю, что это на самом деле делает RISC‑V только хуже, и что мы не должны активно помогать фрагментации.

Так что не ждите, что RISC‑V BE появится в главном ядре Linux.