Pull to refresh

Comments 15

Я так понимаю речь только про группу некоторых драйверов на платформах tier 1, где есть надежный компилятор (или кросс) раста? Или это затронет и само ядро? И что тогда делать платформам из списка tier 2/3?

Ну, надо понимать, что "кросс-платформенных" драйверов особо не бывает, так что проблем с компиляцией драйверов для условного S360 для железки из x86 мира не будет в силу отсутствия поддержки на уровне железа.

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

Это очень опрометчивое утверждение, если это одна и таже железка, которая висит на стандартной шине, то и работать она будет так же. Ну тоесть, что меняется в memory-mapped интерфейсе к железке? Самое большое различие это порядок байт в хостовом процессоре, но это обернуто уже тысячу лет, так же как и работа с прерываниями и dma.

То есть я могу взять условную nvidia PCI-E карту и воткнуть её в армовую машину? Что-то мне подсказывает, что нет. Так же как в S360 или m68k.

Почему нет? Проблема в том, что меняется хост процессор и некоторая обвязка, поэтому драйвера надо перекомпилировать. Но для aarch64 у нвидии драйвера лежат прямо на сайте: https://www.nvidia.com/en-us/drivers/unix

Хм. Интересно. Тогда вопрос о поддержке со стороны компилятора всех платформ линукса становится более острым. Возможно, приход rust/gcc это сгладит...

Ну, надо понимать, что "кросс-платформенных" драйверов особо не бывает, так что проблем с компиляцией драйверов для условного S360 для железки из x86 мира не будет в силу отсутствия поддержки на уровне железа.

Ну здрасьте. У меня на АРМе прекрасно работает интеловская 10гбитная сетевуха. С родными драйверами, естественно.

Собственно все ARM, x64, x82 прекрасно поддерживаются Rust. Они входят в Tier 1. У Tier 2 поддержка тоже хорошая (один черт при разработке ядра и драйверов стандартная библиотека не используется). Все остальное это такие редкостные архитектуры, что если надо то будут писать на C. И драйвера не бывают "кроссплатформенными". Бывают скажем "разработанные вручную под разные платформы":-). И понятно никто не будет разрабатывать драйвер для архитектуры на которой работает 1,5 устройств.

И драйвера не бывают "кроссплатформенными"

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

Драйвера PCI устройств будут посложнее, но тоже в большинстве случаев могут прекрасно работать на любой архитектуре. Могут быть проблемы со всякой дичью типа ROM BAR или port-based IO, но это уже нюансы.

Про драйвера USB устройств я вообще молчу. Там все работает только в путь.

Не кросс-платформенны только драйвера так называемых "platform devices", но тут даже из названия понятно что они не должны быть кросс-платформенными.

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

Сейчас ещё есть проект бекенда на основе gccjit, но пока скорее как порт на платформы, куда llvm не привезли.

Я так понимаю речь только про группу некоторых драйверов на платформах tier 1, где есть надежный компилятор (или кросс) раста?

Вы будете сменяются, но x86_64-unknown-none-linuxkernel — это tier 3

И что тогда делать платформам из списка tier 2/3?

Интереснее что с архитектурами, которые растом вообще не поддерживаются
И это не только/не столько Эльбрус
https://github.com/fishinabarrel/linux-kernel-module-rust/issues/112

Sign up to leave a comment.

Other news