Линус Торвальдс со словами «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. РАНЬШЕ, в том окне слияния. И без мусора.
Оригиналный текст ответа Торвальдса
> RISC-V Patches for the 6.17 Merge Window, Part 1
No. This is garbage and it came in too late. I asked for early pull requests because I’m traveling, and if you can’t follow that rule, at least make the pull requests good.
This adds various garbage that isn’t RISC-V specific to generic header files.
And by «garbage» I really mean it. This is stuff that nobody should ever send me, never mind late in a merge window.
Like this crazy and pointless make_u32_from_two_u16() «helper».
That thing makes the world actively a worse place to live. It’s useless garbage that makes any user incomprehensible, and actively WORSE than not using that stupid «helper».
If you write the code out as «(a << 16) + b", you know what it does and which is the high word. Maybe you need to add a cast to make sure that 'b' doesn't have high bits that pollutes the end result, so maybe it's not going to be exactly pretty, but it's not going to be wrong and incomprehensible either.
In contrast, if you write make_u32_from_two_u16(a,b) you have not a f%^5ing clue what the word order is. IOW, you just made things WORSE, and you added that «helper» to a generic non-RISC-V file where people are apparently supposed to use it to make other code worse too.
So no. Things like this need to get bent. It does not go into generic header files, and it damn well does not happen late in the merge window.
You’re on notice: no more late pull requests, and no more garbage outside the RISC-V tree.
Now, I would hope there’s no garbage inside the RISC-V parts, but that’s your choice. But things in generic headers do not get polluted by crazy stuff. And sending a big pull request the day before the merge window closes in the hope that I’m too busy to care is not a winning strategy.
So you get to try again in 6.18. EARLY in the that merge window. And without the garbage.
Linus
Источник: habr.com