Проблеми, напруга та розбіжності з Rust для Linux уже висвітлюються 

Проблеми з Rust для Linux

Схоже, що цей рік не буде роком Linux, оскільки, хоча в останньому кварталі минулого року все здавалося, що Linux і настільні комп’ютери піднімуться в 2025 році, все не завжди так, як здається.

І це всього кілька днів Крістоф Хельвіг, видатна постать у підтримці критичних підсистем, таких як DMA, KVM, Slab Allocator і PowerPC в ядрі Linux, чітко заявив про свою відмову підтримувати виправлення які сприяють розвитку контролерів у Rust.

Крістоф Хельвіг згадується, що патчі, про які йдеться Вони запропонували включити оболонки навколо функцій підсистеми DMA, щоб дозволити драйверам, написаним на Rust, використовувати її. Однак він стверджує, що ця стратегіяa ускладнює обслуговування коду, і чіткість інтерфейсів C повинна бути збережена, запобігаючи розширенню абстракцій, які можуть перешкоджати інтеграції з рештою ядра.

Проблеми змішування мов у проекті

За словами Хельвіга, Основна проблема полягає в інтеграції коду Rust створює залежності, які змушують розробників підсистеми C враховувати вплив їхніх модифікацій на зв’язувальний код Rust. Це Це означає, що будь-які коригування конструкцій або внутрішні функції в C можуть знадобитися паралельні зміни коду Rust, що створює сценарій, який важко підтримувати в довгостроковій перспективі.

Щоб уникнути цієї ситуації, Hellwig рекомендовано, щоб контролери в 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 продовжує стикатися зі складними проблемами, коли технічні рішення повинні бути ретельно виміряні, щоб забезпечити стійкість проекту в довгостроковій перспективі.


Додати як пріоритетне джерело в Google