Линус Торвальдс категорически высказался против предлагаемой поддержки режима 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.
