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

второе - дурдом.

Ваще обычная история.

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

Иди читай документацию, ты явно не в курсе о чем говоришь.

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

просто у тебя мало опыта :) а есть конторы, где ты будешь свой сотовый класть в шкафчик под ключ у старшего офицера.

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

Иди читай документацию, ты явно не в курсе о чем говоришь.

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

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

просто у тебя мало опыта :) есть конторы, где ты будешь свой сотовый класть в шкафчик под ключ у старшего офицера.

Все так, всю свою профессиональную карьеру я старательно такого опыта избегал. Денег нет, вместо нормальных практик разработки – шиза. Что в этом хорошего ваще непонятно.

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

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

Riiight

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

В реальности у тебя в ядре Linux есть опенсурсные мейнтейнеры, которые координируют работы, в ядре Windows – нет. Ты это оспаривать собрался? :)

Меинтейнеры - это в дистрибутивах и это совершенно бесполезные люди, которые паразитируют на фрагментации Linux как платформы. А в ядре есть разработчи и часть этих разработчиков действительно что-то координирует. Вот только у них не выходит каменный цветок… нормально работающие драйверы. Драйверами должны заниматься производители железа. Игры в швабодку, а дайте нам все спеки, а раскройте нам код проприетарных драйверов, а напишите/перепешите нам драйвер для вот этого потому что мы снова всё поломали, ничего принципиально не меняют. Даже если и удаётся что-то выклянчить.

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

zg
()
Ответ на: комментарий от no-such-file

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

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

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

а когда все в кучу - это бардак неизбежен.

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

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

У меня в конторе код проприетарный. Мы таким не страдаем.

а когда все в кучу - это бардак неизбежен.

Skill issue. Git gut.

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

Меинтейнеры - это в дистрибутивах и это совершенно бесполезные люди, которые паразитируют на фрагментации Linux как платформы.

Я тоже так думал. А потом я посмотрел на то, какой анал карнавал в FlatHub творится. Мейнтейнеры дистров – просто святые люди!

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

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

Что у LOR сегодня с отрицанием реальности? В корне Linux буквально лежит файл MAINTAINERS.

Вот только у них не выходит каменный цветок… нормально работающие драйверы.

Прямо сейчас играю в игрушку в Steam и пишу тебе через WiFi. Как минимум драйвер AMD GPU и WiFi карты работают нормально!

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

Как ты думаешь, кто эти чудесные люди, которыех их пишут?

Игры в швабодку, а дайте нам все спеки, а раскройте нам код проприетарных драйверов, а напишите/перепешите нам драйвер для вот этого потому что мы снова всё поломали, ничего принципиально не меняют. Даже если и удаётся что-то выклянчить.

Ты отстал от жизни лет на десять. AMD сам пишет свой полностью открытый драйвер. Даже NVIDIA сдалась и начала писать нормальный.

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

Так всегда говорят люди, которые не имеют к драйверам и ядрам вообще никакого отношения.

P.S. Драйвер NVIDIA снаружи, если что.

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

Так всегда говорят люди, которые не имеют к драйверам и ядрам вообще никакого отношения.

P.S. Драйвер NVIDIA снаружи, если что.

А сколько рабочих модулей снаружи, которые успевают за ядерными релизами? Я вот только два знаю: nvidia и ZFS.

У Windows и macOS драйверный API достаточно стабилен. Linux тут в меньшинстве.

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

Это просто неудобно, причём ещё на этапе разработки.

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

Какие ещё табы?

Я про блоки отступами, абстрактно.

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

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

Как он был и в Перле. Вот только последнему это не сильно помогло.

Это была наименьшая проблема перла.

Тонны говнокода на Питоне, включая библиотечный код, просто не готовы к strict-mode.

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

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

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

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

Что у LOR сегодня с отрицанием реальности? В корне Linux буквально лежит файл MAINTAINERS.

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

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

Полное говно. Даже в lkml вышло лучше, чем тут.

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

Ничего не понял,

Растовщик пытался просунуть общий растоманский код для работы с DMA в подсистему DMA. Мейнтейнер сказал, что растоманских файлов в свою директори не пустит, что означает, что растовщикам придётся копипастить один и тот же файл по всем своим драйверам.

Растоманский код, к слову, не собирался, потому что растоманы переобувались с маппинга char на u8.

В этот момент ворвался какой-то пчел, пилящий на дому асахи линукс, поначалу с хорошим троллингом:

1

Rust folks: Please don’t waste your time and mental cycles on drama like this. It’s not worth your time. Either Linus likes it, or he doesn’t. Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they’re going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages.

FWIW, in my opinion, the "cancer" comment from Christoph would be enough to qualify for Code-of-Conduct action, but I doubt anything of the sort will happen.

Но дальше он сразу перешёл на помпаж:

2

I’m tired.

I’m tired of seeing positive, technically impressive kernel projects blockaded delayed by maintainers with no technical justification, and at best end up moving along at a glacial pace.

I’m tired of seeing important contributors and maintainers give up and throw the towel after enduring repeated misbehavior and hostility towards their efforts from others.

I’m tired of getting messages, privately and publicly, from all kinds of people, saying they won’t touch the kernel with a 10-foot pole due to the hostility and the baroque, regressive process.

I’m tired of seeing people get away with using words like "cancer" to describe others’ work, with zero repercussion.

I’m tired of politely and calmly calling out hostile and unwelcoming behavior from maintainers and suggest ways to improve, only to be ignored and nothing change (note: this refers to other instances, not this instance).

I’m tired of having to spend hours or days of my time to upstream simple things, because even the simplest of changes en up in a bikeshed.

I’m tired of having to manually format code instead of using clang-format.

I’m tired of drive-by nitpickers who send useless review comments on code they don’t take the time to understand.

I’m tired of having to review patches in an email client, where I can’t even tell which patches are for me to merge and not without writing complex filtering rules to correlate email bodies with kernel subsystem paths, which I don’t have the time to write and maintain.

I’m tired of having to type a half dozen b4 commands just to send a change.

And I’m tired of hearing things will get better if I just "trust the process" or let people work from within, while nothing seems to have actually changed in years despite endless discussion about these problems on the sidelines.

If shaming on social media does not work, then tell me what does, because I’m out of ideas.

И вышел из чата:

3

I’m not talking about individual technical problems. You cannot solve social and community problems with technical arguments.

Yes, given enough patience and technical argumentation, you can get code into the kernel, or maybe even get some existing code refactored. That doesn’t change the fact that the process is often quite terrible, hostile to newcomers, demoralizing, and by wide consensus much worse than practically any other FOSS project, even those of similar scope to the kernel.

And what I see, is very little effort to improve that status quo, or at least very little that yields any actual change that isn’t just band-aids (e.g. tooling like b4, which is nice and appreciated, but doesn’t fix any underlying issues). And that’s not going to change no matter how many long technical arguments we have on the MLs (or even off MLs, since MLs are also not particularly good for this, and I’ve seen multiple arguments only reach a resolution after being redirected to IRC).

But I’ve used up all my spoons for this, and clearly Linus doesn’t think there’s a problem in this thread worth replying to other than myself, so I’m giving up on fighting for any change or being part of the kernel maintainer community. Whether the rest of the kernel community chooses to continue to live in an ugly bubble or actually try to fix some of these systemic issues, is up to them.

Под занавес обвинив всех в том, что они продались корпоратам за деньги и выгоняют на мороз бессеребреников:

4

Oh, and one last thing. I’ve heard that, in whatever backroom conversations you’ve been having about this situation, there has apparently been a belief, explicit or implicit, that I am in any way employed to work on the Linux kernel.

Unlike most people in this thread, I don’t enjoy the luxury of a cushy tech job that pays me to deal with this community. I am supported exclusively by donations, which incidentally, have been steadily decreasing since the start of the Asahi Linux project. The project has zero corporate sponsorship.

And I do believe the fact that essentially all high-level Linux kernel maintainers and contributors are paid by corporations to do it is a major factor that has caused this community to become wildly out of touch with what it means to be a community FOSS project.

Кроме этого разрованного пердака, в общем-то ничего больше и не произошло.

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

Мейнтейнер не хочет Rust в своей подсистеме, в его подсистему никто патчей-то и не предлагал.

Предлагали.

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

А сколько рабочих модулей снаружи, которые успевают за ядерными релизами? Я вот только два знаю: nvidia и ZFS.

Если навскидку, то ещё openvpn-dco, scst, lttng, virtualbox, rtpengine. Какие-то драйверы от broadcom, но я уже не помню точных названй.

Плюс к этому ГРЕБАЯ ПРОРВА вендорских драйверов для стабильных ядер RHEL и SUSE.

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

Предлагали.

Нет, не предлагали. Его просто поставили в известность что обвязку сделают для DMA. Это просто вежливый heads-up.

gaylord
()

«За мной не заржавеет!» (c)Кристоф Хелвиг

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

Плюс к этому ГРЕБАЯ ПРОРВА вендорских драйверов для стабильных ядер RHEL и SUSE.

С этим проще, они поддерживают одну-две версии ядра.

Если навскидку, то ещё openvpn-dco, scst, lttng, virtualbox, rtpengine. Какие-то драйверы от broadcom, но я уже не помню точных названй.

В общем, не так много. Я к чему, есть же вполне официальная политика ядра: вливайся в mainline или умри. Вплоть до того, что ведро с внешним модулем считается tainted и багрепорты тут не примут.

hateyoufeel ★★★★★
()

Будут ли собираться драйвера на аппаратных платформах, на которых полноценный rust недоступен? Для ядра будет какой то особый вариант, какая то надстройка над gcc/clang?

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

С этим проще, они поддерживают одну-две версии ядра.

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

В общем, не так много. Я к чему, есть же вполне официальная политика ядра: вливайся в mainline или умри.

Такой политики нет.

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

Будут ли собираться драйвера на аппаратных платформах, на которых полноценный rust недоступен?

Нет, там проверка на поддеживаемые архитектуры.

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

Предлагали.

Нет, не предлагали. Его просто поставили в известность что обвязку сделают для DMA. Это просто вежливый heads-up.

Это не "вежливое уведомление", это код напрямую работающий с DMA из rust’а:

 rust/bindings/bindings_helper.h |   1 +
 rust/kernel/dma.rs              | 271 ++++++++++++++++++++++++++++++++
 rust/kernel/error.rs            |   1 +
 rust/kernel/lib.rs              |   1 +
 4 files changed, 274 insertions(+)
 create mode 100644 rust/kernel/dma.rs

И именно на это было наложено вето:

No rust code in kernel/dma, please.

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

качество ответов ИИ в вопросах о квик сорт не изменится

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

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

Это не «вежливое уведомление», это код напрямую работающий с DMA из rust’а:

Именно так. Работающй как потребитель, а не являющийся частью подсистемы.

И именно на это было наложено вето

Только это другая директория. kernel/dma затронута не была и новый код туда не добавлен.

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

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

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

В общем, не так много. Я к чему, есть же вполне официальная политика ядра: вливайся в mainline или умри.

Такой политики нет.

Окей, с «официальной» я тут перегнул. Тем не менее, разработка внешних модулей достаточно затруднена в сравнение с другими ОС.

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

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

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

Окей, с «официальной» я тут перегнул. Тем не менее, разработка внешних модулей достаточно затруднена в сравнение с другими ОС.

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

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

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

Нет, это реализация интерфейса работы с DMA на расте. Это не "потребитель", "потребитель" - это другие драйверы, вызывающие интерфейс. Это именно реализация API работы с DMA . Она такая же часть DMA-подсистемы как реализация API работы с ним на си.

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

Нет, это реализация интерфейса работы с DMA на расте. Это не «потребитель» - «потребитель» - это другие драйверы. Это именно реализация API работы с DMA . Она такая же часть DMA-подсистемы как реализация API работы с ним на си.

Конечно нет. Это буквально трансляция сишного API в rust API. Они даже сами об этом пишут:

We wrote a single piece of Rust code that abstracts the C API for all Rust drivers, which we offer to maintain ourselves.

As far as the interaction with C code goes, it appears to be a pretty straightforward midlayer consumer of the DMA API much like others we already have (e.g. videobuf2-dma-*), just one which happens to be a language binding rather than some other kind of functional abstraction.

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

Конечно нет.

Конечно, да.

Это буквально трансляция сишного API в rust API.

Именно. С момента появления этой трансляции у DMA-подсистемы появляется реализация на расте. Так понятно?

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

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

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

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

Именно это пытался заблочить Кристоф.

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

Именно. С момента появления этой трансляции у DMA-подсистемы появляется реализация на расте.

Реализация? Нет, не появляется. Появляются биндинги к сишному коду.

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

Речь не идёт о вызове сишного апи из растовского кода для работы с дма

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

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

Речь не идёт о вызове сишного апи из растовского кода для работы с дма.

Буквально об этом, господи. Ты патч-то видел вообще?

Речь идёт о создании апи на расте, который уже будут вызывать растовские драйвера.

Это называется «биндинги».

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

С момента появления этой трансляции у DMA-подсистемы появляется реализация на расте. Так понятно?

Появляется интерфейс на Rust, а не реализация. Реализация по-прежнему на Си.

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

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

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

Именно это пытался заблочить Кристоф.

Кристоф не хочет второй язык, он очень четко это артикулирует:

Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this. This is NOT because I hate Rust. While not my favourite language it’s definitively one of the best new ones and I encourage people to use it for new projects where it fits. I do not want it anywhere near a huge C code base that I need to maintain.

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

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

Все обсосано миллион раз, люди не могут писать корректный код на C в за разумное время в разумных объемах. Это невозможно, это доказано миллион раз, спорить я про это не хочу.

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

просто запретить выход на рынок продуктов без драйверов linux. в случае нарушения - бить валютой страны пребывания и сбросом в ров с крокодилами.

Крокодилов не хватит и не везде они есть :-)))

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

Тут проблема в том, что не принято чёткое решение по использовмнию Rust в Линуксе. Если бы решение приняли в пользу Rust, то этого мейнтейнера бы наказали за саботаж.

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

там такая лютая железячность,

0_0 да что, чёрт возьми, это означает и как определяется, и почему у раста должны быть проблемы, по сравнению с другими системными языками? Микроконтроллеры - это вот железячность достаточно(недостаточно) лютая? потому что на них вот раст вполне себе работает и удобно программируется, сильно удобнее и приятнее сишки, проверено лично

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

Тут проблема в том, что не принято чёткое решение по использовмнию Rust в Линуксе. Если бы решение приняли в пользу Rust, то этого мейнтейнера бы наказали за саботаж.

Ты пытаешься натянуть логику работы стройотряда на разработку крупнейшего опенсурсного проекта наших дней. Это не сработает.

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

Появляется интерфейс на Rust, а не реализация. Реализация по-прежнему на Си.

Нет. Не "появляется интрефейс", а появляется "реализация интерфейса". Это разные вещи. Когда делают библиотеку для работы с mysql из питона на питоне - это называется "библиотека (== реализация) работы с БД MySQL на питоне", даже если питон по факту использует сишную либу под капотом.

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

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

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

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

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

Несущие выдохнутся, выгорят и уйдут другими делами заниматься.

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

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

Речь идёт о создании апи на расте, который уже будут вызывать растовские драйвера.

Это называется «биндинги».

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

Речь не идёт о вызове сишного апи из растовского кода для работы с дма.

Буквально об этом, господи.

Нет, конечно же. Там есть честны растовский код, имплементирующий свою логику на расте:

+impl Attrs {
+    /// Get the raw representation of this attribute.
+    pub(crate) fn as_raw(self) -> usize {
+        self.0.try_into().unwrap()
+    }
+
+    /// Check whether `flags` is contained in `self`.
+    pub fn contains(self, flags: Attrs) -> bool {
+        (self & flags) == flags
+    }
+}
+
+impl core::ops::BitOr for Attrs {
+    type Output = Self;
+    fn bitor(self, rhs: Self) -> Self::Output {
+        Self(self.0 | rhs.0)
+    }
+}
+
+impl core::ops::BitAnd for Attrs {
+    type Output = Self;
+    fn bitand(self, rhs: Self) -> Self::Output {
+        Self(self.0 & rhs.0)
+    }
+}
+
+impl core::ops::Not for Attrs {
+    type Output = Self;
+    fn not(self) -> Self::Output {
+        Self(!self.0)
+    }
+}
+
...

Ты патч-то видел вообще?

Из нас двоих его явно не видел ты. Да, это обвязка вокруг сишного кода, но у неё есть свой интерфейс и она имеет свою логику:

+    pub unsafe fn read(&self, offset: usize, count: usize) -> Result<&[T]> {
+        if offset + count >= self.count {
+            return Err(EINVAL);
+        }

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

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