Линус Торвальдс со словами «no f%^5ing clue» и «Garbage» жестко отверг изменения архитектуры RISC‑V для кода ядра Linux 6.17. Обновления для RISC-V не войдут в новый цикл, и их придётся повторить для версии 6.18 позднее в этом году. Торвальдс называл по крайней мере часть предлагаемого кода RISC-V мусором, а также ответил разработчикам, что он был отправлен слишком поздно в течение окна слияния.
27 июля 2025 года Линус Торвальдс представил первый стабильный релиз ядра Linux 6.16 под кодовым названием Baby Opossum Posse (Отряд детенышей опоссума). «Стоит отметить, что предстоящее окно слияния для версии 6.17 будет для меня немного хаотичным: в августе у меня несколько семейных событий (свадьба и большой день рождения), и, поскольку семья разбросана не только по США, но и по Финляндии, я проведу около половины месяца в разъездах. Это значит, что я очень постараюсь сделать большую часть окна слияния за первую неделю перед началом моих поездок, и я уже предупредил об этом тех, кто обычно присылает мне больше всего pull requests», — предупредил ранее разработчиков Торвальдс.
Ожидается, что окно слияния Linux 6.17 завершится 10 августа с выпуском Linux 6.17-rc1. Для этой версии ядра предлагалось добавить RISC-V IOMMU к поддержке систем на базе ACPI, поддержку ACPI BGRT для отображения логотипов производителей при загрузке, обходные пути исправления ошибок, поддержку расширения Xmipsexectl, чтение типа MMU из дерева устройств, повышение производительности подкачки с учётом порядка байтов, поддержку kprobetrace, поддержку расширений MPXY и RPMI SBI, а также поддержку целостности потока управления с процессами пользовательского пространства. Однако этот pull request был отклонён Линусом Торвальдсом для Linux 6.17 из-за позднего обновления в окне слияния, особенно учитывая его зарубежные поездки на этой неделе. Он также оказался очень недоволен частью кода, включённого в этот pull request.
Торвальдс написал в рассылке для разработчиков ядра Linux:
«Нет. Это мусор, и он пришёл слишком поздно. Я запросил ранние pull request, потому что я в отъезде, и если вы не можете следовать этому правилу, хотя бы сделайте pull request хорошими.
Это добавляет разный мусор, не специфичный для RISC-V, но относящийся к общим заголовочным файлам.
И под «мусором» я имею в виду именно это. Это то, что мне никто никогда не должен присылать, не говоря уже о том, что он находится в конце окна слияния.
Вроде этого безумного и бессмысленного «помощника» make_u32_from_two_u16().
Эта штука делает мир действительно хуже для жизни. Это бесполезный мусор, который делает любого пользователя непонятным, и он действительно ХУЖЕ, чем отсутствие этого дурацкого «помощника».
Если вы запишете код как «(a << 16) + b», вы знаете, что он делает и где тут high word. Возможно, вам нужно добавить приведение типов, чтобы убедиться, что у «b» нет старших битов, которые загрязняют конечный результат, так что, возможно, он будет не совсем красивым, но и не будет неправильным и непонятным.
Напротив, если вы напишете make_u32_from_two_u16(a,b), вы ни f%^5ing clue не поймёте, какой порядок слов. Вау, вы только всё ХУЖЕ сделали, добавив этот «помощник» в универсальный файл, не относящийся к RISC-V, где, по-видимому, предполагается его использование для ухудшения другого кода.
Так что нет. Такие вещи нужно игнорировать. Это не попадает в универсальные заголовочные файлы и, чёрт возьми, не происходит поздно в окне слияния.
Вы предупреждены: больше никаких поздних pull request и никакого мусора за пределами дерева RISC-V.
Теперь я надеюсь, что внутри частей RISC-V нет мусора, но это ваш выбор. Но в универсальных заголовках не должно быть ничего лишнего. И отправка большого pull request накануне. Окно слияния закрывается в надежде, что я слишком занят, чтобы беспокоиться об этом, — невыигрышная стратегия.
Так что вы можете попробовать ещё раз в версии 6.18. РАНЬШЕ, в том окне слияния. И без мусора.
>>> Подробности
