[ON] Кризис в продвижении Rust в ядро из-за опасений усложнения сопровождения

[rssbot]

Кристоф Хелвиг (Christoph Hellwig), мэйнтейнер подсистем DMA, KVM, Slab Allocator и архитектуры PowerPC в ядре Linux, в своё время входивший в управляющий технический комитет организации Linux Foundation и выступавший истцом в связанном с GPL судебном разбирательстве с VMware, отказался подтверждать патчи, связанные с поддержкой разработки драйверов на языке Rust. Предложенные патчи добавляли обвязки над несколькими функциями подсистемы DMA, позволяющие использовать DMA в драйверах на языке Rust.


В качестве причины отказа упомянуто усложнение сопровождения кода при наличии обвязок на других языках и желание сохранить программные интерфейсы к DMA в читаемом виде на языке Си, без размазывания по непонятным обвязкам. Кристоф предложил напрямую обращаться к исходному Си API DMA в каждом драйвере на языке Rust, чтобы не создавать дополнительных абстракций, от которых вынуждены будут зависеть сопровождающие ядра.



Разработчики патчей указали, что они возьмут на себя всю работу по сопровождению кода на Rust, готовы сопровождать эти патчи самостоятельно и вынесли обвязки в отдельный подкаталог (rust/kernel/dma.rs). В ответ Кристоф наложил вето ("Nacked-by") на приём связанных с Rust патчей и указал, что ему не нужен ещё один сопровождающий. Кристоф заявил, что если разработчики обвязок хотят добиться невозможности сопровождения Linux из-за смешивания нескольких языков в одной кодовой базе, им следует делать это в своём драйвере, а не распространять эту раковую опухоль на основные подсистемы ядра.


При этом Кристоф уточнил, что не имеет ничего против языка Rust и считает его одним из лучших новых языков, но он против смешивания кода на разных языках. По словам Кристофа он за создание новых проектов на Rust, но против примешивания Rust к большим кодовым базам на Си, так как такое смешивание сильно снижает
удобство сопровождения ядра, как интегрированного проекта.







Суть проблем с сопровождением в том, что Rust-обвязки ставят сопровождающих в зависимость от кода на языке Rust. На первый взгляд кажется, что обвязки лишь надстройки над Си-структурами и функциями, которые никак не влияют на разработку и сопровождение кода на Си. Но это не так. При наличии подобных обвязок разработчики подсистем, написанных на Си, должны учитывать влияние их изменений на продолжение работоспособности обвязок. Любое изменение структур данных или внутренних функций на Си может привести к необходимости изменения кода обвязок, поэтому влияющие на обвязки изменения в Си коде нужно отслеживать и синхронизировать с кодом на Rust. Многие сопровождающие не готовы брать на себя дополнительную ответственность за исправление проблем, возникающих в коде на Rust, и не намерены тратить своё время на отслеживание состояния Rust-обвязок.


Ситуация с усложнением сопровождения не умозрительная. К дискуссии подключился Джейсон Ганторп (Jason Gunthorpe), мэйнтейнер TPM, VFIO и Infiniband из компании NVIDIA, который привёл пример отклонения Линусом Торвальдсом pull-запроса с изменениями в подсистеме управления памятью, так как данное изменение приводило к сбою при попытке сборки ядра с включением поддержки Rust. Сбой возник из-за того, что сопровождающие код на Rust не добавили необходимые изменения в генератор обвязок (bindgen). Таким образом, сопровождающие
подсистему управления памятью при продвижении изменения, полностью корректного с точки зрения кода на Си и ядра в целом, оказались зависимы от опционального стороннего кода в ядре, за который отвечают другие люди.


Отказ принимать код обвязки над вызовами DMA поставил разработчиков проекта Rust for Linux в тупик, так как без подобных обвязок разработка полноценных драйверов на языке Rust будет затруднена. Гектор Мартин (Hector Martin), мэйнтейнер кода для поддержи ARM-чипов Apple и лидер проекта Asahi Linux, в качестве варианта разрешения конфликта предложил добиться принятия обвязки напрямую через Линуса Торвальдса, в обход сопровождающего подсистему DMA. Если Линус согласится на подобное нарушение субординации и сложившейся практики, это может привести к кризису управления разработкой ядра, а если откажется - остановит продвижение Rust в ядро.



Как вариант, Гектор упомянул привлечение Кристофа к ответственности за нарушение кодекса поведения из-за комментария, в котором Кристоф сравнил Rust с раковой опухолью. Кроме того, Гектор написал, что устал от всех бюрократических проволочек, не готов просто довериться сложившимся процессам и намекнул на привлечение внимания к проблеме в социальных сетях. Дэйв Эйрли (Dave Airlie), мэйнтейнер подсистемы DRM, посоветовал не раздувать конфликт и понять, что токсичное поведение недопустимо с обеих сторон, независимо от того, прав или не прав участник дискуссии.


К обсуждению подключился Линус Торвальдс, который указал, что проблема возможно в самом Гекторе и его самоуверенности в том, что он знает что-то лучше других, а не в текущем процессе разработки ядра, который работает. У процесса разработки ядра есть проблемы, но это жизненная реальность - в жизни нет ничего идеального. Попытки травли через социальные сети - это то, что отбивает желание у Линуса иметь что-либо общее с подходом Гектора. Значение для Линуса имеют технические обсуждения и патчи, а не оказание давления через социальные сети.


В ответ Гектор отправил запрос на удаление себя из числа сопровождающих платформу ARM/Apple, так как он потерял веру в применяемый в ядре процесс разработки и подход к управлению сообществом. Он также заявил, что разработка платформы ARM/Apple будет продолжена вне основного ядра Linux. У платформы ARM/Apple в ядре остался ещё один мэйнтейнер - Свен Питер (Sven Peter), который намерен продолжить поддержание платформы в ядре своими силами.








Источник: https://www.opennet.ru/opennews/art.shtml?num=62685
(opennet.ru, основная лента)

[yoricI]

Правильно, пущай валят, форкаются и делают что хотят, хоть на бейсике.

[ormorph]

Само собою всё это усложняет сопровождение. Кому только это надо было на столько усложнять это всё. Если бы проект был коммерческим, то любые капризы за ваши деньги. А тут не понято, что они вообще пошли на поводу этого.
Я тут глянул вчера ради интереса на коменты в проекте TDE который когда то поддерживал, и понял что не зря я кинул всё это. Если кто в теме, то тут компилятор не находит прототип функции pthread_setname_np, при этом заголовочник с функцией объявлен в файле. Тут не нужно быть профессором, что бы понять что не подключён макрос включающий это. Достаточно даже просто прочитать man по этой функции. Вот только этот макрос включается компилятором c++ по умолчанию в любом Linux. Тут вопрос где он достал такой компилятор вообще, так как в Gentoo такого как правило нет. И мне нужно было каждый раз это кому-то объяснять. Само собою добавлять этот макрос просто так нельзя в тот код, так как это собирается не только под Linux, например под FreeBSD. Языком всегда всё просто.