Похоже, этот год не станет годом Linux, поскольку, хотя в последнем квартале прошлого года все выглядело так, что Linux и настольные компьютеры начнут пользоваться популярностью в 2025 году, на самом деле все не всегда так, как кажется.
А всего несколько дней назад Кристоф Хеллвиг, видный деятель в области поддержки критически важных подсистем, таких как DMA, KVM, Slab Allocator и PowerPC в ядре Linux , ясно дал понять, что он не поддерживает патчи , облегчающие разработку драйверов на Rust.
Кристоф Хеллвиг упоминает, что рассматриваемые патчи предлагали включать обертки вокруг функций подсистемы DMA, чтобы позволить драйверам, написанным на Rust, использовать ее. Однако он утверждает, что такая стратегия усложняет сопровождение кода и что следует сохранять ясность интерфейсов C , избегая расширения абстракций, которые могут препятствовать интеграции с остальной частью ядра.
Проблемы смешивания языков в проекте
По словам Хеллвига, главная проблема заключается в том, что интеграция кода Rust создает зависимости, которые вынуждают разработчиков подсистемы C учитывать влияние своих изменений на код компоновки Rust. Это означает, что любые изменения внутренних структур или функций C могут потребовать параллельных изменений в коде Rust, что создает ситуацию, которую трудно поддерживать в долгосрочной перспективе.
Чтобы избежать этой ситуации, Хеллвиг рекомендовал драйверам на Rust обращаться к собственному API DMA на языке C напрямую, вместо того чтобы прибегать к дополнительным оберткам, которые, по его мнению, поставили бы под угрозу удобство сопровождения ядра.
Разработчики , предложившие патчи, утверждали, что будут поддерживать код на Rust, и с этой целью организовали ссылки в специальном подкаталоге (rust/kernel/dma.rs). Однако Хеллвиг наложил вето на эти предложения, предупредив, что ему не нужно брать на себя ответственность за интеграцию кода из других языков в основные подсистемы.
Кроме того, он настоятельно рекомендовал превратить ядро в мозаику из нескольких языков, начать следует с драйверов Rust, а не навязывать эту сложность в фундаментальных областях.
Споры обострились, когда такие деятели, как Джейсон Ганторп, разработчик TPM, VFIO и Infiniband в NVIDIA, привели примеры того, как изменения в подсистемах памяти, хотя и корректные с точки зрения кода на C, вызывали проблемы при попытке скомпилировать ядро с поддержкой Rust. Эти инциденты продемонстрировали, что связи между C и Rust могут приводить к появлению дополнительных зависимостей, препятствующих скоординированной разработке.
Стоит отметить, что обсуждение не ограничивалось техническими аспектами. Эктор Мартин предположил, что решением может стать прямое подключение через Линуса Торвальдса, минуя разработчика подсистемы DMA. Однако такой подход может нарушить традиционную иерархическую структуру разработки ядра.
Гектор также указал на поведение, которое он считал токсичным, даже упомянув, что критика Хеллвига, в которой тот сравнил Rust с «раковой опухолью», способствовала его разочарованию и, в конечном итоге, решению уйти с поста сопровождающего платформы ARM/Apple в основном ядре. Несмотря на его отставку, платформа продолжит поддерживаться Свеном Петером, который обязался продолжать ее обслуживание.
Линус Торвальдс присоединился к обсуждению , подчеркнув, что процесс разработки ядра , хотя и несовершенен, работает, и что технические дискуссии должны быть сосредоточены на исправлениях , без влияния внешнего давления или травли в социальных сетях. По мнению Торвальдса , основное внимание должно быть уделено исключительно техническим вопросам, оставляя личные споры в стороне.
Отказ Кристофа Хеллвига включить оболочки Rust в подсистему DMA подчеркивает напряженность между разработчиками ядра Linux. В то время как некоторые рассматривают Rust как мощный инструмент для создания новых проектов, другие опасаются, что интеграция нескольких языков может затруднить поддержку и согласованность кодовой базы.
Ситуация остается предметом дискуссий и может иметь существенные последствия для будущего поддержки Rust в ядре. В любом случае ясно одно: сообщество разработчиков Linux продолжает сталкиваться со сложными задачами, где технические решения должны тщательно продумываться для обеспечения долгосрочной устойчивости проекта.