Товальдс в роли великодушного пожизненного диктатора Linux решил перенести код sched_ext в ветку Linux 6.11

По данным Phoronix, код sched_ext оказался достаточно универсальным для повышения производительности игр в Linux, более быстрого прототипирования новых изменений планировщика, а разработчики из Ubuntu/Canonical высоко оценили этот проект на предмет микроядерного дизайна и многих других интересных подходов при работе с Linux. Тем не менее, эта разработка оставалась долгое время вне основной ветки, но сейчас ситуация меняется с предстоящим циклом разработки Linux 6.11.

Честно говоря, я не вижу причин больше откладывать это. Весь этот набор исправлений был основным (частным) обсуждением на прошлогоднем саммите разработчиков ядра, и я не вижу никакой ценности в таком же обсуждении (будь то вне списка или в качестве фактическоего события) на предстоящем саммите сопровождающих год спустя, поэтому, чтобы добиться какого-либо разумного прогресса, мой текущий план — объединить это для версии 6.11.

По крайней мере, в этом отношении мы добиваемся прогресса, и обсуждение на KS 2024 может быть посвящено моей остроте ума – или ее отсутствию – а не перефразированию того же самого, что явно не принесло никакого прогресса в прошлом году.

Я никогда не был большим сторонником попыток сделать всех счастливыми с помощью кода, находящегося вне основной ветки — нам лучше работать над ним вместе, внутри ветки.

И использование аргумента «чтобы принять это, сначала нужно исправить что-то еще» тоже не очень хорошо работает (и это обсуждалось более десяти лет на различных саммитах сопровождающих проекта).

Возможно, разработчики, у которых есть опасения по этому поводу, смогут поработать над этими проблемами, когда это будет внутри ветки проекта.

Я также не верю в аргумент, который использовался (несколько раз) о том, что BPF scheduler будет препятствовать участию мейнтейнеров в дальнейшей разработке кода планировщика. Лично я считаю, что главное, что удерживает разработчиков от участия, — это слишком высокие барьеры для участия.

В любом случае, я обращаюсь к Tejun с просьбой просто отправить мне запрос на включение для следующего окна слияния.

И для всех остальных как предупреждение: «Это происходит». [Пожалуйста, просто мысленно вставьте сюда гифку-мем «ЭТО ПРОИСХОДИТ» — потому что, если бы я действительно включил его сюда, lkml просто отклонил бы это письмо. Иногда анти-html правила работают не в нашу пользу].

Линус.

Читайте так же:

• Билл Гейтс: проблему потребления энергии ИИ-системами решат технологии

Таким образом, если не считать каких-либо изменений планов в последнюю минуту в период с настоящего момента до середины июля, когда откроется окно слияния Linux 6.11, патчи для sched_ext появятся в следующем цикле разработки ядра Linux.

В мае Торвальдс в переписке в списке рассылки по поводу обсуждения возможности смягчения неожиданных арифметических переполнений/недополнений/зацикливания в исходном коде C ядра Linux посоветовал Кису Куку из Google быть решением, а не проблемой в рамках работы с мейнтейнерами ядра Linux, а также перестать плодить неразумные жалобы на код компилятора.

12 января 2024 года Линус Торвальдс обозвал %^!@$% новый код Intel Xe для DRM (Direct Rendering Manager) в Linux 6.8. Он сам исправил его огрехи и призвал сторонних разработчиков и мейнтейнеров проекта тестировать, тестировать и ещё раз тестировать свои патчи.

В апреле в рамках подготовки патчей для Linux 6.9-rc4 Линус Торвальдс решил бороться с парсерами конфигурационных файлов Kconfig, которые не могут правильно обрабатывать табуляции. Торвальдс написал патч, чтобы намеренно добавить несколько собственных табов в Kconfig, чтобы отбросить любые внешние или сторонние парсеры, которые не могут их правильно обработать. Торвальдс намеренно добавил эти скрытые табы в общий файл Kconfig для обработки размеров страниц ядра. Таким образом, это обязательно приведёт к серьёзным и заметным ошибкам для любых парсеров, не имеющих правильную обработку табов.

В декабре 2023 года Торвальдс рассказал об усталости сопровождающих ядра проекта. По его мнению, сопровождающие ядра Linux должны уметь смотреть на код других людей и обладать возможностью ответить на вопрос: «Это хороший или плохой подход?».

В октябре 2022 года Торвальдс отчитал ментейнеров проекта версии ядра Linux за постоянный срыв дедлайнов и расслабленность в работе. В своём обращении к разработчикам Торвальдс также обратился к тем, кто сдаёт ему проделанную работу после заявленного срока. «Привычку откладывать всё до последнего нужно было оставить в школе. Это совершенно не подходит для разработки ядра Linux», — написал Торвальдс.