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)
Ответ на: комментарий от zabbal

< Это если бы просто очередную хрень ради хайпа тащили какие-то энтузиасты. Rust объективно безопаснее С при сравнимой производительности поэтому корпорации, которые преимущественно и разрабатывают ядро Linux, непременно его туда затащат. Выдохнутся эти - наймут новых, делов-то.

На какую корпорацию работает Мигель Огеда?

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

Значение имеет то, что есть работающий интерфейс на неком языке. Что там под капотом в реализации - уже не важно.

Ты пытаешься выдать желаемое за действительное.

Нет, я просто использую термины в их строгом значении, а на пытаюсь фривольно растянуть понятия или подменить одно другим.

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

Нет, не называется. Биндинги - это когда ты маппишь некоторые элементы кода из программной библиотеки на символы у себя в коде 1:1. Здесь не этот случай.

И дальше ты приводишь буквально это.

Если бы это был чистый маппинг 1:1 - то этих проверок не должно было бы быть.

Ты сейчас всерьезно будешь пытаться убеждать меня что однострочные функции это «собственная реализация»? И каким образом это вообще влияет на тот факт, что это находится вне DMA подсистемы, которую мейнтейнит Кристоф? Изменилась бы ситуация если бы этот файл хардлинками размазали по каждому растовому драйверу?

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

Там уже внедрили CoC и применяют его. Точно также можно добавить правило на запрет оказания препятствий внедрения кода на Rust.

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

Нет, я просто использую термины в их строгом значении, а на пытаюсь фривольно растянуть понятия или подменить одно другим.

Давай обратимся к Википедии:

In programming and software design, a binding is an application programming interface (API) that provides glue code specifically made to allow a programming language to use a foreign library or operating system service (one that is not native to that language).

Нет ни слова про 1:1 и невозможность обеспечивать инварианты.

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

На какую корпорацию работает Мигель Огеда?

С чего ты решил что Rust в ядро продвигает единственный человек?

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

Там уже внедрили CoC и применяют его.

CoC это способ модерировать дискуссию.

Точно также можно добавить правило на запрет оказания препятствий внедрения кода на Rust.

А это приказным порядком объявленное решение.

Чувствуешь разницу?

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

Нет. Не «появляется интрефейс», а появляется «реализация интерфейса».

Это откуда вы взяли такую странную терминологию?

Когда делают библиотеку для работы с mysql из питона на питоне - это называется «библиотека (== реализация) работы с БД MySQL на питоне»

Нет. Это называется обёртка или биндинг.

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

И дальше ты приводишь буквально это.

Ты не умеешь читать код на расте или что?

Ты сейчас всерьезно будешь пытаться убеждать меня что однострочные функции это «собственная реализация»?

Нет, конечно. Я тебе прямым текстом озвучивают факт из «спокойной ночи малыши» - если в новом API есть хоть одна проверка на входные данные, которой нет в оригинальном API - это уже другой инвариант на входные данные. Другая логика. Другая реализация. Не важно, сложная она или простая. Инварианты уже другие. Всё, этого достаточно, чтобы считать это самостоятельным API, не тождественным оригинальному.

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

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

Шансов нет потому что у GNU сообщеста отрицательное отношение к CMake.

Поэтому они продолжают мучиться со своими Autotools и прочими костылями?

Это какая-то виндузятская утилита, разрабатываемая коммерческой конторой.

Почему виндузятская? Буква C в названии официально расшифровывается как cross platform. Лицензия BSD-3-Clause, код и Git репозиторий открыты. Хочешь форкай, хочешь контрибьють. Какие проблемы? Проект изначально начинался на деньги United States National Library of Medicine, что скорее всего усложнит его закрытие в будущем.

А Meson разрабатывается сообществом и в первую очередь ориентирован на Unix-like системы (хотя Windows тоже поддерживается).

Такого рода системный софт, ориентированный на Unix-like следовало бы изначально писать на основном ЯП любой Unix-like системы, то есть на Си.

Meson лучше интегрируется, например потому что использует pkg-config для определения зависимостей. А у CMake свой формат.

У CMake кроссплатформенная архитектура, в отличии от…

https://www.reddit.com/r/cpp/comments/el9b0u/why_cmake_encourages_distributing_its_cmake_files/

Some time ago it was a standard that must libraries distributed XYZ.pc files for pkg-config that could be later consumed by any build system (or none). Recently I see trend that it’s encouraged to distribute appropriate FindXYZ.cmake or XYZConfig.cmake.

Why is that so? What additional information can be conveyed through cmake files that is crucial for libraries?

A lot of things, actually. pkg-config only supports passing a set of compiler flags and linker flags. This is already an issue if you’ve got a compiler using a different syntax. Most UNIX compilers support -I and -L syntax for includes and linker folders, but if you need any other compiler flags, you will limit compiler interoperability.

Problem number two are compiler specific parts like modules - C++ (and Fortran) modules are not binary compatible between compilers. For Fortran, it has been long established practice to provide separate include folders for the various compilers you want to support. A library that does this would be Intel MPI for instance, they ship Intel and various GFortran modules out of the box, and their compiler wrapper includes different folders depending on the underlying compiler. If you were to package such a library in a pkg-config file, this behavior simply cannot be implemented, whereas a CMake script can make such a selection. Once C++ modules become common place, this will look similar on that front.

Problem number three is cross-compilation. Since pkg-config is a program running on the host, cross-compilation is a bit cumbersome and you need some wrapper script for it, see here. A CMake script has no such quarrels due to the way CMake handles cross-platform pathing automatically and needs no further adjustments.

Problem number four is Windows. You simply cannot use pkg-config outside of MinGW or Cygwin since it’s not made to support that. For CMake scripts, this isn’t an issue.

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

CoC это способ модерировать дискуссию.

Написал против Rust – пошёл в бан. Чем не модерирование дискуссии? Механизм работы тот же.

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

Ты не умеешь читать код на расте или что?

За всей этой пассивной агрессией что-то скрывается или ты просто так?

если в новом API есть хоть одна проверка на входные данные, которой нет в оригинальном API - это уже другой инвариант на входные данные

Это уже твои какие-то личные тараканы. Вся суть растовых абстракций (так тебе комфортнее?) эти инварианты обеспечить. В этом суть(tm). Что не делает этот код частью DMA подсистемы ни в коей мере.

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

Когда делают библиотеку для работы с mysql из питона на питоне - это называется «библиотека (== реализация) работы с БД MySQL на питоне»

Нет.

Не, "нет", а да. Хватит отрицать реальность. Прямо в первой же строчке выдаче гугла будут формулировки "how to install mysqlclient python library in linux?"

Это называется обёртка или биндинг.

Биндинг - это то, что делается через cffi и аналоги. То, что идёт в виде своего пакета - уже будет библиотекой.

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

Проект изначально начинался на деньги United States National Library of Medicine, что скорее всего усложнит его закрытие в будущем.

CMake разрабатывается коммерческой конторой KitWare.

Такого рода системный софт, ориентированный на Unix-like следовало бы изначально писать на основном ЯП любой Unix-like системы, то есть на Си.

Опять же есть готовый к использованию Muon, где ничего не надо кроме компилятора C99. Даже Make не надо.

У CMake кроссплатформенная архитектура, в отличии от…

В Meson *.pc зависимости прекрасно работают и в Windows с MSVC. Там Meson умеет транслировать флаги компилятора если надо. Так что с кроссплатформенностью всё в порядке.

А вот в CMake зачем-то решили сделать свой формат описания зависимостей вместо де-факто стандарта pkg-config.

Также GNU сообществу вообще плевать на совместимость с Windows, а вот совместимость с pkg-config, который также используется в Autotools – это большой плюс.

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

Это уже твои какие-то личные тараканы.

Нет, это формальные определения терминов.

Вся суть растовых абстракций эти инварианты обеспечить

Ты с водой выплеснул ребёнка. Речь не про то, что "вся суть раста", речь про тождественность инвариантов. Если код на расте её не обеспечивает (не важно по каким причинам) - это уже не "обёртка" и не "биндинг", а своё самостоятельное API со своими интерфейсами и инвариантами. Реализация API, отдельно замечу.

И ещё раз повторю для тугодумов - количественное соотношение значения не имеет. Имеет тождественность.

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

Дело не в базарной разработке. Это конкретно линуксовая шиза. Договориться о стабильном API можно даже в рамках базара.

Какой-то внутренний API существует уже сейчас. Сейчас, если необходимо что-то в нём изменить, это можно сделать с двух сторон силами одной команды - и со стороны основного кода ядра и со стороны драйверов, которые в нём же. В случае стабильной API пришлось бы поддерживать какую-то совместимость, что ударило бы по свободе мысли разработчиков ядра, привыкших «базарить». Полагаю, что основной аргумент Торвальдса сводился примерно к этому. А иначе какой смысл сопротивляться? Во, например, сисколы ядра - это тоже некоторый API и он совместим вниз, но он уже устоялся, то есть стал кафедральным. Разве не так?

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

mysqlclient python library

Где там слово «implementation»?

Это какое-то новое слово в тупняке на лоре. Давай по шагам:

  1. Является ли "mysqlclient python library" "library" ?
  2. Является ли "mysqlclient python library" "python library" ?
  3. Является ли "mysqlclient python library" "python library" для "mysql"?
  4. Имеет ли какое-либо значение для ответа на предыдущие три вопроса тот факт, что "mysqlclient python library" использует сишную реализацию "mysqlclient"?
LamerOk ★★★★★
()
Ответ на: комментарий от X512

библиотека (== реализация

Это ещё откуда?

Из определения термина, пчел:

In computing, a library is a collection of resources that is leveraged during software development to implement a computer program. Commonly, a library consists of executable code such as compiled functions and classes, or a library can be a collection of source code.

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

Шансов нет потому что у GNU сообщеста отрицательное отношение к CMake

Ну тупые (c)
CMake - де факто стандарт для C++ (ну и для C тоже). Ещё 10 лет назад можно было об этом спорить, но сейчас это уже не подвержит сомнению.

Это какая-то виндузятская утилита

Ты явно в другой реальности живешь. CMake есть везде. И все пакетные менеджеры ориентируются на CMake: conan, vcpkg, CPM - все работают на линуксе. Так же CVake может подключить зависимости из github, pkg-config, make, или вообще из рандомных дирректорий в системе (т.е. найти что-то в /usr/local).

Сейчас кроссплатформенный проект сделать на C++ на CMake - как два пальца об асфальт.

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

Нет, это формальные определения терминов.

Давай ссылку.

Ты с водой выплеснул ребёнка. Речь не про то, что «вся суть раста», речь про тождественность инвариантов. Если код на расте её не обеспечивает (не важно по каким причинам) - это уже не «обёртка» и не «биндинг», а своё самостоятельное API со своими интерфейсами и инвариантами. Реализация API, отдельно замечу.

Давай назовем это абстракциями. Так лучше?

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

conan, vcpkg

Это всё для виндузятников. Зачем это всё в Линуксе, когда есть apt, yum и т.п.?

CMake - де факто стандарт для C++ (ну и для C тоже).

Только у виндузятников. У разработчиков под Линукс и MacOS другое мнение.

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

Оригинальной кафедральной разработки больше никогда не будет, по крайней мере у свободного ПО. Напомню что кафедралтная разработка – это когда все ресурсы разработки, такие как репозиторий, issue tracker и т.д. доступны только официалтным разработчикам проекта. А публике доступны только архивы с исходниками релизов без истории изменений.

Под кафедральной разработкой я имел в виду то, как разрабатываются *BSD. Например FreeBSD изначально и до сих пор разрабатывается как единая операционная система, без сотен ненужных дистрибутивов, альтернативных систем инициализации, альтернативных libc и прочей альтернативщины. Там нет всего этого зоопарка, который мы наблюдаем в мире Linux. Другое дело, что им не повезло на начальном этапе из-за судебных разборок с AT&T и интерес большинства корпораций ушёл в Linux.

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

Только у виндузятников. У разработчиков под Линукс и MacOS другое мнение.

cmake используется для сборки огромной кучи софта под лялекс.

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

Давай назовем это абстракциями. Так лучше?

Да, ты можешь называть это хоть трансцендентными абстракциями. Сути дела это не меняет - была предложена единая реализация API для работы с DMA-подсистемой для драйверов на rust’е.

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

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B1%D0%BE%D1%80_%D0%B8_%D0%91%D0%B0%D0%B7%D0%B0%D1%80

Соборная модель, когда исходный код становится доступным с выходом каждого нового релиза программы, но во время работы над очередным релизом доступ к коду разрешён лишь ограниченному кругу разработчиков проекта. Как пример приводятся проекты GNU Emacs и GCC.

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

новому поколению инклузивных зуммеров никто не мешает запилить свою ОС, а не лезть в чужую.

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

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

Да, ты можешь называть это хоть трансцендентными абстракциями. Сути дела это не меняет - была предложена единая реализация API для работы с DMA-подсистемой для драйверов на rust’е.

Ага. Которая не была частью DMA подсистемы ядра и являлась, как правильно заметили авторы патча, midlayer’ом. И драма была вообще необоснована ничем, кроме нежелания Кристофа видеть Rust в core части ядра. Потому что его это все не касается никак: ему не надо это чинить, ему не надо это ревьювить, он вообще об этом знать не знает. Ничего бы не изменилось, если бы этот файл скопировал себе каждый драйвер (он буквально это и предлагал).

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

Не важно работает или нет. Важно то, что зачем оно нужно, когда есть пакетный менеджер дистрибутива с devel пакетами.

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

Потому что его это все не касается никак: ему не надо это чинить, ему не надо это ревьювить, он вообще об этом знать не знает. Ничего бы не изменилось, если бы этот файл скопировал себе каждый драйвер (он буквально это и предлагал).

Так в том то и дело что как раз само существование rust в ядре даже если ты его не трогаешь еще как касается, вот прям одна из ситуаций:

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

единая реализация API для работы с DMA-подсистемой для драйверов на rust’е.

Которая не была частью DMA подсистемы ядра

Как ты себе это представляешь? Ну, вот чисто логически - как API работы c VFS могут быть не частью VFS? Как kernel-API для работы c сетевыми пакетами могут быть не частью сетевого стэка? Вот буквально для любой подсистемы ядра.

У меня не получается.

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

А проще? А пруфы есть?

Какие пруфы тебя устроят? Я исхожу из предположения, что меньше ядер поддерживать – меньше работы.

Разработки сторонних драйверов для ОС RHEL? Стабильный интерфейс на 10 лет и вообще никаких проблем.

Ты сам выше писал:

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

Это явно отличается от ситуации в Windows, где можно выпустить одну бинарную сборку и она будет работать в Windows 10 и скорее всего в Windows 11.

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

Потому что его это все не касается никак: ему не надо это чинить, ему не надо это ревьювить, он вообще об этом знать не знает.

Насчёт «никак» можно и усомниться. Можно, например, предположить что он увидел в этом некие зачатки EEE. Как выше заметили, даже одна строчка логики внутри обёрток – это уже развитие идеи, а не биндинг.

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

Да не важно часть это или не часть. Оно в любом случае будет ломаться при изменении Си интерфейса, а значит патчи будут отклонять, пока не починят код на Rust вместе с изменением Си интерфейсов.

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

Причём тут растофилы, когда out-of-tree драйверы запрещает Торвальдс

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

Когда-то очень давно я участвовал в проекте под названием «Рука Москвы», который Ростелеком использовал в качестве развлекухи на всяких международных выставках в начале 2000-х. Это типа дистанционный армрестлинг. Два девайса с торчащей металлической рукой с мощным приводом, сенсорами давления/положения/скорости и т.п. которые были связаны через инет и позволяли двум людям в разных местах земного шара побороться руками. Реал-тайм и всё такое. Так вот, работой девайсов управлял комп на линуксе в который была воткнута сделанная специально под проект кастомная интерфейсная ISA карточка под которую был, разумеется, написан out-of-tree драйвер. Как ты думаешь, насколько меня волновало мнение Торвальдса об out-of-tree драйверах когда я писал и отлаживал оный драйвер?

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

Так что все эти растофильские отмазки на предмет «Линус запрещает» и пр. не канают вообще.

Нет никаких проблем писать и поддерживать out-of-tree драйвера под линукс не требуя вообще ничего ни от Линуса ни от разрабочиков ядра. Вне зависимости от языка на котором они написаны. Абсолютно все, кто утверждает иное, на самом деле хотят вовсе не писать драйвера под линукс, а заниматься всякой своей содомией в головах у разработчиков линукса.

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

который привёл пример отклонения Линусом Торвальдсом pull-запроса

Вообще-то, он не про это. Он про то, что растовые биндинги влияют на сборку ядра, и если в расте что-то сломалось, то ядро не собирается, и соответственно коммиты не проходят дальше по воркфлоу, пока раст не починят:

I tested this theory, allnoconfig x86 build, enable 64 bit, rust and
PCI only. *NO* Rust drivers enabled.

Make a hypothetical C API change:

       --- a/include/asm-generic/pci_iomap.h
       +++ b/include/asm-generic/pci_iomap.h
       @@ -18,7 +18,7 @@ extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
	extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
					       unsigned long offset,
					       unsigned long maxlen);
       -extern void pci_iounmap(struct pci_dev *dev, void __iomem *);
       +extern void pci_iounmap(struct pci_dev *dev, void __iomem *, unsigned int flags);
	/* Create a virtual mapping cookie for a port on a given PCI device.
	 * Do not call this directly, it exists to make it easier for architectures
	 * to override */
       diff --git a/lib/iomap.c b/lib/iomap.c
       index 4f8b31baa5752a..5b63063a1a811f 100644
       --- a/lib/iomap.c
       +++ b/lib/iomap.c
       @@ -421,7 +421,7 @@ EXPORT_SYMBOL(ioport_unmap);
	#ifdef CONFIG_PCI
	/* Hide the details if this is a MMIO or PIO address space and just do what
	 * you expect in the correct way. */
       -void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
       +void pci_iounmap(struct pci_dev *dev, void __iomem * addr, unsigned int flags)
	{
	       IO_COND(addr, /* nothing */, iounmap(addr));
	}

And the result is..

       error[E0061]: this function takes 3 arguments but 2 arguments were supplied
	  --> ../rust/kernel/pci.rs:320:13
	   |
       320 |             bindings::pci_iounmap(pdev.as_raw(), ioptr as _);
	   |             ^^^^^^^^^^^^^^^^^^^^^--------------------------- an argument of type `u32` is missing
	   |
       note: function defined here
	  --> /tmp/x/build/rust/bindings/bindings_generated.rs:3:1444598
	   |
       3   | ...> * mut ffi :: c_void ; } extern "C" { pub fn pci_iounmap (dev : * mut pci_dev , arg1 : * mut ffi :: c_v...
	   |                                                  ^^^^^^^^^^^
       help: provide the argument
	   |
       320 |             bindings::pci_iounmap(pdev.as_raw(), ioptr as _, /* u32 */);
	   |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Build fails.

Can't seem to fix this using kconfig without turning off CONFIG_RUST,
exactly the same outcome as Uros's case.

Doesn't seem "much much much different" to me.

This shouldn't be surprising. It doesn't work like C. Rust builds the
PCI bindings always once CONFIG_PCI is turned on. It doesn't matter if
no rust driver is being built that consumes those bindings. It won't
work like staging does where you can just turn off one driver.
LamerOk ★★★★★
()
Ответ на: комментарий от liksys

На этапе разработки просто сразу используй контейнер, и всё. Я бы мог понять эту претензию лет 15 назад, но сейчас разработка в контейнере - это де-факто стандарт.

На кой хрен мне контейнер для разработки? Ты ещё предложи делать это в виртуалке под каким нибудь VirtualBox, как делает один мой коллега из под Винды с Федорой.

Никаких поводов, уже все пользуются в питоне пробелами.

А позже появится новое поколение, которому табы милее и в их ЯП они таки не будут конфликтовать с пробелами. Мы ведь обсуждаем именно это, а не как договорились в Питоне после долгих срачей.

Вообще не проблема, strict-mode можно включать для пользовательского кода. В библиотеках уже всё и так годами оттестировано.

Не получится. Там уже привыкли говнокодить и strict-mode не приживётся.

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

Я просто не понимаю зачем тащить всю эту скриптоту в стандартный тулинг POSIX системы. Причём скриптота совершенно POSIX-ом не предусмотренная, в отличии от скриптов на шелл. Так и до Си компилятора на Питоне не далеко. Питон для этого плохо подходит и единственная мотивация разрабов Meson использовать именно Питон, как я понимаю, заключается в том, что они его просто знают и пишут быстрее сишников.

Посмотри на историю Git vs Mercurial. Последний написан именно на Питоне и он почти не взлетел.

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

Вообще-то, он не про это. Он про то, что растовые биндинги влияют на сборку ядра, и если в расте что-то сломалось, то ядро не собирается, и соответственно коммиты не проходят дальше по воркфлоу, пока раст не починят:

Как раз про это. Теперь разработчику надо еще и с rust кодом разбираться либо ждать пока разработчик rust соизволит сделать исправление. То-есть rust мешает разработчику C. В случае с C кодом он легко сам сделает нужное исправление.

Надо было изначально писать rust драйверы out-of-tree. И уже если эти драйверы докажут превосходство начать думать о возможном включении в ядро.

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

Рядовая история, которая раздулась только потому что там слово «rust» присутствует. Это буквально обычный вторник для ядра.

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

Ситуация напоминает оную с Xorg и Wayland.

а уже собрались энтузиасты переписывать xorg, wayland на руст?

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

они договориться не могут про интерфейс к сишным драйверам. видали проблему! она решается в 10 минут. растоманы просто не хотят ничего решать, скорее всего.

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

Как ты себе это представляешь? Ну, вот чисто логически - как API работы c VFS могут быть не частью VFS? Как kernel-API для работы c сетевыми пакетами могут быть не частью сетевого стэка? Вот буквально для любой подсистемы ядра.

Ты просто в философию укатился. Подсистема здесь это четко очерченная зона ответственности. А вот эта штука – это rust DMA allocation abstraction и живет она в отдельной директории с отдельными мейнтейнерами. Все просто же.

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

так они старые драйверы переписывают или на новые замахнулись?

Зависит от конторы. NVIDIA новый драйвер несет, Asahi тоже. Кто-то какие-то NVMe драйверы хотел мигрировать.

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

На кой хрен мне контейнер для разработки?

Затем, что помимо питоновых исходников, твой софт зависит еще и от системных библиотек. Это как бы хорошая идея - запускать твой код в том окружении, в котором он будет использоваться в продакшне.

А позже появится новое поколение, которому табы милее и в их ЯП они таки не будут конфликтовать с пробелами

Если бы да кабы.

Не получится. Там уже привыкли говнокодить и strict-mode не приживётся.

Там - это где? В новых проектах используются тайп-хинты, все там прекрасно приживется.

Я просто не понимаю зачем тащить всю эту скриптоту в стандартный тулинг POSIX системы.

Затем, что это лучший язык для написания сложной бизнес-логики, не требующей большой производительности со стороны cpu-bound. Более того, язык живой и развивающийся.

Посмотри на историю Git vs Mercurial. Последний написан именно на Питоне и он почти не взлетел.

Он не взлетел не из-за питона, а из-за использования гита ядром, и сопутствующего хайпа вокруг него. А гитхаб вогнал последний гвоздь в крышку гроба.

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

Какие пруфы тебя устроят?

Понятия не имею. Поэтому я и не делаю никакие далеко идущие вывода из предположений. У нас есть два факта:

  • Почти все крупные сетевые вендоры поддерживают актуальную версию драйверов для (как минимум) трех мажорных версий RHEL и трех мажорных версий SUSE. И регулярно бекпортируют из свежих ядер фиксы и фичи. И делают новые релизы для минорных релизов этих дистрибутивов. А ещё там Oracle с UEK часто присутствует.

  • Я из головы вытащил почти десяток out-of-tree драйверов, которые нашлись в репозитория арча.

И как-то вот нормально люди живут.

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

Ну наверное, но «меньше ядер – меньше работы» и «out-of-tree не работает говножопасотона» это довольно далекие друг от друга мысли :)

gaylord
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.