TG Telegram Group & Channel
Rust | United States America (US)
Create: Update:

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

Кристоф Хелвиг (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 в ядро из-за опасений усложнения сопровождения

Кристоф Хелвиг (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.
Please open Telegram to view this post
VIEW IN TELEGRAM


>>Click here to continue<<

Rust




Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)