LINUX.ORG.RU

Кризис при продвижении языка программирования Rust в ядро Linux

 , ,

Кризис при продвижении языка программирования Rust в ядро Linux

2

5

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

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

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

Неcмотря на высказанное разработчиками проекта Rust for linux намерение о полностью самостоятельном сопровождении написанной на Rust кодовой базы, на прием патчей было наложено вето.

Кристоф отметил, что если разработчики хотят добиться невозможности сопровождения Linux из-за смешивания в одной кодовой базе разных языков программирования, им следует делать это в своём драйвере, а не распылять эту «раковою опухоль» на основное ядро.

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

>>> Подробности (OpenNet)



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 5)
Ответ на: комментарий от Aber

Софт который мне не слишком важен, например Gimp, LibreOffice ставлю как есть в дистре. Запускаю я его раз в несколько месяцев и пользуюсь от силы 5% функций. Мне не нужны новые фишки, главное чтоб не падало.

Ну и какая тогда разница какой использовать дистрибутив?

X512 ★★★★★
()
Ответ на: комментарий от Obezyan

дополнительный слой абстракции ВСЕГДА ведет к усложнению

Ну хз, программируй тогда в машинных кодах, раз так проще. Имхо, слои абстракция, когда они не лишние, все упрощают

pihter ★★★★★
()
Ответ на: комментарий от X512

Ну и какая тогда разница какой использовать дистрибутив?

Я не уживаюсь с RR дистрами. Был опыт. После обновлений какой-то софт сегфолтится на своих же старых конфигах (в моем случае это происходило не единожды с tilda (терминал такой)), в etc нужно мержить конфликты вручную (конфиги демонов, загрузчика, правила udev), звук может перестать работать, может перестать работать только микрофон и об этом узнаешь только на утреннем созвоне, значит придется неловко извиняться в чате.

Aber ★★★★★
()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от X512

Там разные версии софта, разные политики стабилизации, разные поддерживаемые опции ядра. Понятно что в идеальном мире пользовательский софт ставится через что-то типа flatpak, но базовая система у всех все равно постоянно разная получается.

gaylord
()
Ответ на: комментарий от Aber

Я не уживаюсь с RR дистрами.

У того же Debian есть как стабильные LTS релизы, так и аналог rolling release. Или RHEL/Fedora.

X512 ★★★★★
()
Ответ на: комментарий от X512

Ну вот, люди пользуются тем что им удобно. Мне удобна ubuntu.

Ну я могу покритиковать ту же ubuntu, слишком много всего бекпортируется в стабильные ядра и они становятся вовсе не такими стабильным. Система может просто не загрузиться после очередного «минорного» обновления ядра, т.е. вот допустим у родителей, бабушки, дедушки где-то в другом городе/стране работает штабильная убунта… и в один момент она просто не загружается :(
Это не глобальная проблема, что-то поломалось в работе драйвера с конкретной железкой которая оказалась в том злосчастном компе. В среднем это случается раз в 1-2 года на одном из устройств.

В общем я бы хотел чтоб такой ситуации не случалось, но пока так.

Просто интересно, в windows такое не случается?

Aber ★★★★★
()
Последнее исправление: Aber (всего исправлений: 2)
Ответ на: комментарий от X512

Ну и какая тогда разница какой использовать дистрибутив?

У них слегка разные областит применения. Использовать RHEL на десктопе будет тем ещё удовольствием.

gaylord
()
Ответ на: комментарий от Aber

Система может просто не загрузиться после очередного «минорного» обновления ядра

В Haiku это красиво решено через запоминания предыдущих состояний установленных пакетов при каждом обновлении, так что если что-то пойдёт не так, в меню загрузки можно выбрать одно из предыдущих состояний пакетов. При том это не снапшоты ФС и данные пользователя назад не откатываются.

Просто интересно, в windows такое не случается?

Чтобы Windows после обновления перестал загружаться, это что-то очень редкое. И там есть безопасный режим с отключением пользовательских драйверов, точки восстановления.

X512 ★★★★★
()
Ответ на: комментарий от X512

Сотрудникам больших корпораций разве не RHEL на рабочие станции устанавливают?

Сотрудники больших корпораций разве не страдают?

gaylord
()
Ответ на: комментарий от X512

точки восстановления.

Безопасный режим есть а вот точек восстановления нет. Так что тут windows будет лучше убунты.

Aber ★★★★★
()
Ответ на: комментарий от X512

За большие деньги наверное можно и пострадать.

Ну вот тебе и ответ.

P.S. Обычно сотрудники больших корпораций с большими деньгами могут ставить себе все, что захотят. RHEL у всех остальных.

gaylord
()
Ответ на: комментарий от X512

Чтобы Windows после обновления перестал загружаться, это что-то очень редкое. И там есть безопасный режим с отключением пользовательских драйверов, точки восстановления.

Из последних : https://telecomdaily.ru/news/2024/07/19/globalnyy-sboy-v-sistemah-windows-ne-povliyal-na-rabotu-aeroportov-v-rossii

mx__ ★★★★★
()
Ответ на: комментарий от mx__

Издание сообщает, что ЧП спровоцировало обновление, подготовленное поставщиком услуг кибербезопасности компанией CrowdStrike. Это решение широко используется многими компаниями по всему миру для управления безопасностью ПК и серверов с Windows.

ССЗБ. Не надо ставить сомнительный софт для слежки за работниками.

X512 ★★★★★
()
Ответ на: комментарий от gaylord

Мы только что выяснили, что для полноценной микроядерности не хватает только upci.

Нет, не выяснили. Мы выяснили, что для минимальной работы драйверов в юзерспейсе не хватает upci. Для полноценной микроядерности в юзерспейс нужно будет вынести всё остальное: дисковую подсистему (включая кэш), VFS, сеть, управление памятью и так далее. В пространстве ядра останутся только код для проверки прав доступа, обработчики прерываний и ещё по мелочи.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Для полноценной микроядерности в юзерспейс нужно будет вынести всё остальное: дисковую подсистему (включая кэш), VFS, сеть, управление памятью и так далее. В пространстве ядра останутся только код для проверки прав доступа, обработчики прерываний и ещё по мелочи.

L4Linux - L4 микроядро где весь Linux запускают в юзерспейсе со всем его добром. По тем тестам что гуглится не так уж и сильно это всё проседает, а ведь оно даже не заточенно под микроядро. Можно взять и сравнить с нативным вариантом.

V1KT0P ★★
()
Ответ на: комментарий от hateyoufeel

Мы выяснили, что для минимальной работы драйверов в юзерспейсе не хватает upci.

Хватит кокетничать уже.

Для полноценной микроядерности в юзерспейс нужно будет вынести всё остальное: дисковую подсистему

Зачем выносить дисковую подсистему? Достаточно вынести драйверы конкретных устройств. Это уже есть. ublk резвый как понос.

VFS

Зачем выносить VFS?

сеть

Уже там.

управление памятью

Не так важно, можно и в ядре оставить.

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

Это все обсуждаемо. То что ты так хочешь, не значит что оно так обязано быть.

gaylord
()
Ответ на: комментарий от V1KT0P

L4Linux - L4 микроядро где весь Linux запускают в юзерспейсе со всем его добром. По тем тестам что гуглится не так уж и сильно это всё проседает, а ведь оно даже не заточенно под микроядро. Можно взять и сравнить с нативным вариантом.

Ну да, потому что они всё ядро засунули в один юзерспейсный процесс. Потому и не проседает. Это фактически вариант паравиртуализации, как в Xen было.

hateyoufeel ★★★★★
()
Ответ на: комментарий от gaylord

Это все обсуждаемо. То что ты так хочешь, не значит что оно так обязано быть.

Это не я так хочу, это всё следует из определения термина «микроядро».

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от X512

Ну вряд ли в Аэропортах ставили сомнительный софт, то что это не от МС не означает что Windows тут ни причем.

mx__ ★★★★★
()
Ответ на: комментарий от mx__

Проблема в сторонней софтине CrowdStrike для слежки за пользователем. У неё кстати есть версия и для Линукса.

X512 ★★★★★
()
Ответ на: комментарий от X512

И что? Ни разу не видел компьютеры с голой windows. Но сколько раз видел админов рвущих на себе волосы и откатывающих очередное обновление windows на wsus.

mx__ ★★★★★
()
Ответ на: комментарий от hateyoufeel

Потому его обычно и не держат в гите. Он должен генерироваться при подготовке тарбола с source release.
В любом случае у autotools огромное количество недостатков, он здесь приведён был только как пример, что ничего не надо устанавливать/бутстрапить.
На деле же ещё как приходится поскольку эти самые source release никто не делает и приходится запускать autogen.sh

mittorn ★★★★★
()
Ответ на: комментарий от gaylord

К сожалению разработчики-идиоты везде найдутся. Что-то подобное любит выдавать wxwidgets, выдавая ошибку о поломанном abi в рантайме

mittorn ★★★★★
()
Ответ на: комментарий от vbr

Ну ладно, вот ещё одна строчка

В таких случаях, компилятор не анализирует настолько глубоко. Подозреваю, из-за того что, это существенно повлияло бы на время компиляции. А вот санитайзер прекрасно отлавливает:

$ cc -g -fsanitize=address,undefined -fsanitize-address-use-after-return=always -fsanitize-address-use-after-scope -fno-omit-frame-pointer 1.c
$ ./a.out 
=================================================================
==3287==ERROR: AddressSanitizer: stack-use-after-return on address 0x000802a02020 at pc 0x0000002827ec bp 0x7fffffffe990 sp 0x7fffffffe138
READ of size 6 at 0x000802a02020 thread T0
    #0 0x0000002827eb in printf_common(void*, char const*, __va_list_tag*) asan_interceptors.cpp
    #1 0x0000002851e6 in printf (/tmp/a.out+0x2851e6)
    #2 0x00000038bddd in main /tmp/1.c:11:3
    #3 0x0008004ebff3 in __libc_start1 (/lib/libc.so.7+0x82ff3)
    #4 0x00000024a39f in _start (/tmp/a.out+0x24a39f)

Address 0x000802a02020 is located in stack of thread T0 at offset 32 in frame
    #0 0x00000038bca7 in get_string /tmp/1.c:3

  This frame has 1 object(s):
    [32, 38) 's1' (line 4) <== Memory access at offset 32 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return asan_interceptors.cpp in printf_common(void*, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
  0x000802a01d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a01e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a01e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a01f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a01f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x000802a02000: f5 f5 f5 f5[f5]f5 f5 f5 00 00 00 00 00 00 00 00
  0x000802a02080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a02100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a02180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a02200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000802a02280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3287==ABORTING

valgrind тоже видит.

iron ★★★★★
()
Ответ на: комментарий от hateyoufeel

Это не я так хочу, это всё следует из определения термина «микроядро».

Это абстрактная идея. Примерно как странные люди все ещё верят что есть «леваки» и «праваки» другие странные люди верят что есть чистые монолитные ядра и чистые микроядра. Лялекс, в котором запросто можно написать ФС в пространстве пользователя по факту не является монолитным. Мы можем придумать термин «гибридные», если тебе будет проще.

gaylord
()
Ответ на: комментарий от mittorn

К сожалению разработчики-идиоты везде найдутся. Что-то подобное любит выдавать wxwidgets, выдавая ошибку о поломанном abi в рантайме

Я к тому что эта проблема есть буквально везде. Это постоянная история, кто-то взял слишком новую зависимость и сломал какое-то старье. Ваще никак не привязано ни к языку, ни к области, ни к чему. Разработчикам не будут тратить свое время чтобы выяснять какая же там актуальная версия зависимостей в oldstable Debian.

gaylord
()
Ответ на: комментарий от seiken

Полная цитата не позволит тебе так легко сменить конкретную тему на удобную и предаться софистика, как ты это делаешь здесь

cobold ★★★★★
()
Ответ на: комментарий от gaylord

у всех подходов есть недостатки. один уходит, его место занимают 10 других. еще раз нафига оно надо. не трогай то что и так работает.

antech
()
Ответ на: комментарий от gaylord

Это не я так хочу, это всё следует из определения термина «микроядро».

Это абстрактная идея.

Это не абстрактная идея. Это технический термин с вполне определённым значением и связанными с ним критериями.

другие странные люди верят что есть чистые монолитные ядра и чистые микроядра.

Так они и правда есть. OpenBSD – чистое монолитное ядро, даже ядерных модулей нет. L4 и около – чистое микроядро.

Мы можем придумать термин «гибридные», если тебе будет проще.

Его уже придумали и очень давно.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от antech

еще раз нафига оно надо. не трогай то что и так работает.

Если бы этой мантре следовали, ядро бы до сих пор сидело с BKL, без нормального mq и cgroups. Этой админская дури «да плохое зато хоть как-то работает и мне страшно что-то менять» не место в хороших проектах.

gaylord
()
Ответ на: комментарий от hateyoufeel

Это не абстрактная идея. Это технический термин с вполне определённым значением и связанными с ним критериями.

И отсутствующими реализациями.

Так они и правда есть. OpenBSD – чистое монолитное ядро, даже ядерных модулей нет. L4 и около – чистое микроядро.

Да нет конечно. В openbsd есть tun, позволяющий сетевые драйверы писать.

Его уже придумали и очень давно.

Ну и вот. Лялекс даже близко не монолит. А дальше вопрос насколько много всего надо наружу вытолкать чтобы стало хорошо.

gaylord
()
Ответ на: комментарий от gaylord

Это не абстрактная идея. Это технический термин с вполне определённым значением и связанными с ним критериями.

И отсутствующими реализациями.

https://en.wikipedia.org/wiki/QNX

https://en.wikipedia.org/wiki/PikeOS

https://github.com/seL4/seL4

Вот тебе три.

Да нет конечно. В openbsd есть tun, позволяющий сетевые драйверы писать.

Да да, конечно. Возможности делать драйвера через tun/tap там очень ограничены.

Ну и вот. Лялекс даже близко не монолит.

Я разве утверждал, что лялекс монолит? Я утверждаю, что лялекс не является микроядром. Потому что и правда не является.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Вот тебе три

Это все эмбеддед и прочая срань.

Да да, конечно. Возможности делать драйвера через tun/tap там очень ограничены.

О господи…

Я разве утверждал, что лялекс монолит? Я утверждаю, что лялекс не является микроядром. Потому что и правда не является.

Если честно не помню, я по инерции пишу.

gaylord
()
Ответ на: комментарий от gaylord

Это все эмбеддед и прочая срань.

Ага. Как раз места, где требуется особенная надёжность, иначе весь девайс по гарантии придётся менять плюс платить неустойки и, возможно, компенсировать ущерб. Для запускалки KDE, емакса и докера это не так актуально, там лялекса вполне хватает.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

gaylord
()
Ответ на: комментарий от gaylord

Но в rust не нужно сидеть на debian oldoldmamont чтобы поймать таккую проблему.
В gentoo стабильная ветка довольно свежая. Тем не менее, я обновил систему, после чего на следующий день попытался собрать проект, который использует какую-то тулзу-обёртку для ndk. Этот cargo-ndk там ставится прямо из билдскрипта, всегда качая последнюю версию, но только если тулза не установлена. Стоит ли говорить что у разраба проекта с той же версией rust всё работало - ведь у него эта утилита поставилась раньше...
Сама утилита ставится, собирается, но в рантайме сыпет ошибкой, что сообрана со слишком старой версией rust... но я ведь день назад собрал rust последней стабильной версией из portage...
На вопрос «какого хрена» к разрабу тулзы он ответил чтобы я ему платил если хочу чтобы моя версия rust поддерживалоась :)
Конечно решилось установкой более старой версии крейта, но случай весьма показательный для экосистемы rust в целом

mittorn ★★★★★
()
Ответ на: комментарий от gaylord

чем оно плохое? 30 лет было хорошее и тут вдруг стало плохим? никаких страхов ни у кого нет. просто это нововедение 10 шагов назад. когда ресурсы можно потратить на дальнейший апгрейд.

antech
()
Ответ на: комментарий от gaylord

С пользователями Дебиана проблем нет, но есть проблема с дистром - он слишком уж сильно тянет с новыми версиями и подобная ситуация в любтм языке там - вопрос времени. А так - сам пользуюсь иногда дебианом в тех случаях, когда это меня устраивает.
Насчёт сищных проектов, что там такое может произойти плохо верится. Если это не какое-то UB с багом компилятора конечно. Новые стандарты в Си очень редко появляются и их очень мало используют, потому на корректном коде такая ситуация крайне маловероятно.
На говнокоде вроде системы сборки qt - да пожалуйста. Qt-шники лезут куда не надо, пытаются распарсить вывод версии компилятора чтобы включитькакие-то костыли и потом это всё через 2 года собрать практически переально - но это c++, а не си и проект довольно спецефичный

mittorn ★★★★★
()
Ответ на: комментарий от antech

30 лет было хорошее и тут вдруг стало плохим?

Запряг коня чтобы завтра ехать на работу? Или все-таки на машине? На конях-то дольше ездили.

никаких страхов ни у кого нет. просто это нововедение 10 шагов назад.

У Кристофа есть. Прямым текстом говорил.

когда ресурсы можно потратить на дальнейший апгрейд.

Можешь попробовать рассказать Линусу куда ему ресурсы тратить.

gaylord
()
Ответ на: комментарий от gaylord

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

antech
()
Ответ на: комментарий от iron

Ладно, попробую объяснить, видимо это не всем очевидно.

В Rust вся система типов, весь язык сделан так, что ты эту ошибку без unsafe не допустишь никак.

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

То, что ты показываешь - это уже не C. Это тулинг вокруг C. Эвристики компилятора отлавливают самые простейшие баги. Более сложные тулзы отлавивают баги посложней. Но должно быть очевидно, что все баги они не отловят. Иначе таких багов бы не было, а они есть.

valgrind это вообще другое. И без valgrind эта программа печатает мусор, тут семи пядей во лбу быть не надо, чтобы понять, что что-то не так. valgrind штука хорошая, но она тебе не поможет, если эта функция выполняется редко. К примеру это обработчик ошибки, который ты при тестировании не вызываешь. А вот хакер вызовет и почитает, чего у тебя там в стеке интересное лежит. А может и модифицирует. Ну и без хакеров багов хватает. Продакшн под valgrind-ом не запустишь. И под виндой valgrind не запустишь. И на микроконтроллере valgrind не запустишь. И ядерный драйвер под valgrind вроде не запустишь, раз уж мы тут ядро обсуждаем.

И, да, все эти valgrind-ы и линтеры это следствие недостаточной строгости C. Которую приходится компенсировать более строгими инструметами. Это вся полезно и нужно, и в Rust это нужно, там тоже не все баги ловятся языком, и unsafe тоже никто не отменял.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.