Где код Rust не просто означает код Rust [1] - привязки (bindings) не выглядят как идиоматический код Rust, они совсем другой вид зверя, пытающегося преодолеть огромный семантический разрыв. И они не делают этого в нескольких местах, потому что они показаны в каждой маленькой подсистеме и библиотеке прямо сейчас.
Таким образом, мы заставим эти привязки ползать повсюду, как раковая опухоль, и очень быстро перейдём от программного проекта, который допускает и стремится к глобальным изменениям, которые улучшают общий проект, к увеличению компартментализации [2]. Это превращает Linux в проект, написанный на нескольких языках, без чётких указаний, какой язык должен использоваться для чего [3]. Даже за пределами привязок большая часть кода не будет очень идиоматичным Rust из-за структур данных ядра, которые навязчивы и ссылаются на себя, как структуры данных, такие как вездесущие связанные списки. Разве мы не оказываем медвежью услугу как тем, кто пытается перенести существующую кодовую базу в лучшее, более безопасное пространство, так и разработчикам, занимающимся системным программированием на Rust?
Работая с такой кодовой базой, это стало моим худшим кошмаром, потому что постоянно приходится переписывать части с языка A на язык B по причине X, а затем обратно по причине Z. И это без обычного «творческого» процесса Linux, когда мейнтейнеры борются друг с другом.
Я хотел бы понять, в чём заключается цель этого «эксперимента» Rust: если мы хотим исправить существующие проблемы с безопасностью памяти, нам нужно сделать это для существующего кода и найти способы его модернизации. В последнее время в это было вложено много работы, и нам нужно гораздо больше. Но это также показывает, как основных мейнтейнеров отпугивают тривиальные вещи, такие как проверка на переполнение целочисленных значений или принудительная синхронизация компилятора (как в clang thread sanitizer). Как мы собираемся преодолеть разрыв между частью ядра, которая даже не принимает относительно простые правила для улучшения безопасности, и другой, которая применяет даже строгие правила?
Если мы просто хотим упростить написание драйверов, новый язык для этого добавляет ещё больше работы и увеличивает нагрузку на и без того перегруженных разработчиков, поддерживающих основную инфраструктуру в должной форме.
Что касается меня, то я могу справиться и справляюсь с самим Rust, мне бы хотелось перенести ядро в более безопасный для памяти мир, но работа с неконтролируемой многоязыковой кодовой базой — это довольно верный способ заставить меня тратить своё свободное время на что-то другое. Я слышал, как несколько других разработчиков бормочут что-то подобное, но не все столь откровенны.
[1] Я написал и работал над довольно большим количеством пользовательского кода Rust, но я ни в коем случае не эксперт, так что отнеситесь к этому с долей скепсиса.
[2] Идея драйверов в eBPF, как это сделано HID, также не помогает в этом так же, как мне нравится eBPF для некоторых случаев использования.
[3] Если только Линус не заставит его встроиться в вашу подсистему, или Дэйв не решит, что все, что касается оборудования Nvidia, должно быть в Rust, конечно.