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

Тогда глючный или неработающий и тем более отсутствующий драйвер будет больно бить производителей железа долларом по заднице.

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

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

Потому что это его политика не поддерживать out-of-tree драйвера.

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

Но, коненчно же, ни о каких приличиях растофилы не в курсе. Никчёмные, но наглые, высокомерные и невоспитанные создания. Аналогия уже прослеживается, да?

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

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

Так оно из коробки так работает, ты можешь импортировать только публичные функции.

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

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

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

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

С чего бы вдруг?

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

Существует реализация языка сборки Meson на C99 под названием Muon. Это даже портативнее чем CMake.

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

Ещё есть упомянутый @gag -ом boson, по поводу которого у меня те же вопросы.

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

Код, который не компилируется – это и не код вовсе

ЛОЛ. Т.е. текст на китайском – это и не текст вовсе. Замечательная жизненная позиция.

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

Пусть продолжают и оставят ядро в покое.

Они не собираются тебя слушать.

В чём причина тряски-то?

В истеричках с LOR.

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

Так оно из коробки так работает, ты можешь импортировать только публичные функции.

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

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

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

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

Могут. Зачем этим заниматься отдельный вопрос, но могут.

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

И ещё есть шанс, что там таки одумаются и перейдут на CMake.

Шансов нет потому что у GNU сообщеста отрицательное отношение к CMake. Это какая-то виндузятская утилита, разрабатываемая коммерческой конторой. А Meson разрабатывается сообществом и в первую очередь ориентирован на Unix-like системы (хотя Windows тоже поддерживается). Meson лучше интегрируется, например потому что использует pkg-config для определения зависимостей. А у CMake свой формат.

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

То, что он организовал разработку openbsd, openssh и ещё пачку проектов, тебя не смутило? Они не сами собой зародились, и чтобы вся эта армада аутистов, пихающих туда код, не пересрались друг с другом, нужен таки талант организатора. В впопенсорце очень не хватает способных менеджеров, которые могут вот такое вот. Код-то писать любой задрот может.

Ну посмотри на автора SerenityOS, который написал и OS и GUI и даже браузер с нуля на C++. Тео форкнул готовую NetBSD, OpenSSH - это так же форк ssh 1.2.12 от Tatu Ylönen. Ну то есть я не пытаюсь принизить программерские скилы Тео, он там и сам много чего написал, но ничего из ряда вон выходящего я в нём не вижу. Раздул срач, хлопнул дверь, форкнул то, форкнул это, а заинтересованный народ сам подтянулся. Пришлось как-то с ним общаться, в переписке. Довольно неприятный тип.

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

парням из R4L пофиг

Там свой чатик есть, причём инициатор настолько бомбанул что «вышел из чата». Раз уж их здесь нет, а ты за них впрягся, я и хочу у ТЕБЯ узнать, от чего их так бомбит.

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

Там свой чатик есть, причём инициатор настолько бомбанул что «вышел из чата». Раз уж их здесь нет, а ты за них впрягся, я и хочу у ТЕБЯ узнать, от чего их так бомбит.

Я ни за кого не впрягался, тебя дезинформировали.

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

Зачем этим заниматься отдельный вопрос, но могут.

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

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

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

Ну ок, слился так слился.

Жизнь полна разочарований.

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

out-of-tree драйвера именно для того и делаются out-of-tree чтобы Линусу&Co не приходилось их поддерживать.

Нет. Их всё равно поддерживают разработчики, просто в рамках ядра. Драйвера без поддержки выкидывают.

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

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

Ты мне сейчас начнешь залечивать что из rust нельзя вызвать функцию из динамического ELF или что?

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

Для этого надо стабилизировать драйверный API. А этого никогда не случится, потому что Лойнус высрал stable-api-nonsense.txt и яростно придерживается. Т.е. пока Лойнус у руля, ядро будет монорепой.

Да это проблема. Базарная организация разработки оказалась таки хуже кафедральной, несмотря на все увещевания Эрика Рейманда в конце 90-х.

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

есть в русте аналог сишного хидера или definition модуля modula-2?

Конечно нет, они там не нужны. Но это ортогонально твоим приключениям с блобом.

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

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

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

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

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

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

Нет, тут все однозначно. ИИ делает так как в обучающем материале, и точка. От качества обучающего материала и от его количества зависит очень много. Так устроен ИИ.

От того, что ИИ обучат квик сорту на миллионе примеров кода вместо сотне тысяч примеров качество ответов ИИ в вопросах о квик сорт не изменится. Я именно это хотел до тебя донести, но ты как-то не понимаешь.

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

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

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

А зачем?

Как минимум, чтобы не было вот этого срача, когда изменения в сишном коде ломают кому-то код на Rust.

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

Да нет, это отличный пример этой проблемы. Есть 100500 разных телефонов на Android, говнороутеров от D-Link и так далее. Что делать с их поддержкой?

  1. Закинуть её в mainline? Он и так жирный, а будет ещё жирнее.
  2. Поддерживать вечно снаружи? Это ещё больший геморрой.
  3. В итоге выбирается худшее из возможного: форкнуть ядро, наложить кучу непонятных говнопатчей, продать девайс и забить.

Я это к тому, что подход с запихиванием поддержки вообще всего подряд в одну монорепу явно не работает.

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

Конечно нет, они там не нужны. Но это ортогонально твоим приключениям с блобом.

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

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

хидер, что я тебе дал - это контракт. я гарантирую, что такие функции будут реализованы.

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

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

Да нет, такого в свободном ПО довольно много. Тот же sqlite возьми. Исходники выложены на публику, но и всё на этом. Авторы даже патчей не принимают.

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

У кода на Расте есть вполне конкретная спецификация. И если написанный текст не соответствует этой спецификации – то это не код на Расте и компилятор отказывается его компилировать. Чего тут непонятного? Точно также компилятор Раста откажется компилировать текст на китайском языке.

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

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

ой, а давай-ка проверим твой пример

#include <stdio.h>

char *get_string(void) {
    char string[] = "hello";
    return string;
}

int main(void) {
    char *s = get_string();
    printf("%s\n", s);
}
$ /opt/homebrew/bin/gcc-14 main.c
main.c: In function 'get_string':
main.c:5:12: warning: function returns address of local variable [-Wreturn-local-addr]
    5 |     return string;
      |            ^~~~~~

очередной растоман не умеет программировать. «Впрочем, ничего удивительного» (с)

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

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

Зачем это все? Ты пишешь модуль, в нем все нужные функции в виде заглушек. Его все подключают, по мере дописания ты пушишь новые версии. Все.

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

И что твоя проверка показала? Что код откомпилировался и запускается? warning-и это не часть языка.

Ещё один защитник C, не знающий даже основ языка, которые он рвётся защищать.

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

Любой проект под code available лицензиями. Они либо от тебя CLA затребуют с кучей бумаги, либо просто твой код не примут.

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

Зачем это все? Ты пишешь модуль, в нем все нужные функции в виде заглушек. Его все подключают, по мере дописания ты пушишь новые версии. Все.

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

как это решается в русте? то есть принудительное лишение постороннего программера знаний о реализации данного ему контракта?

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

Любой проект под code available лицензиями.

Это не open source.

Можете предложить хотя бы пять примеров значимого открытого ПО, которое публикуется только в виде архивов с исходниками во время релиза?

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

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

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

потому что контракт на обьекты не распространяется на их реализацию.

Ага.

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

Какая странная совместная разработка.

как это решается в русте? то есть принудительное лишение постороннего программера знаний о реализации данного ему контракта?

Конечно. Выкладываешь свою скомпилированную срань и её влинковывают.

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

Это уже малоактуально в эпоху докеров.

Это просто неудобно, причём ещё на этапе разработки. Вместо того, чтобы сказать как в Java возьми зависимость из такого-то места, тебе надо городить venv и закачивать туда зависимости из списка зависимостей.

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

Какие ещё табы? Разве ты не знаешь, что в однобортном… с табами теперь никто не воюет? В Перле приняты пробелы, а со свидетелями табов бой там давно выигран. Вот кстати ещё один повод для срачий в будущем.

Учитывая, что в последние годы в языке много чего накрутили, не исключено, что в будущем появится strict-mode.

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

Не лишь, а вполне неплохо. Это показатель того, что язык активно развивается.

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

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

Это не open source.

Это open source. Код открыт.

Можете предложить хотя бы пять примеров значимого открытого ПО, которое публикуется только в виде архивов с исходниками во время релиза?

Ты прицепился к исходникам в тарболе, но так никто не делает. Код зеркалируется на github, при этом участвовать в разработке не дают.

Из наиболее жирного такого есть Unreal Engine, кстати. VSCode туда же, хрен ты в него патч присунешь. Chromium и прочие электроны. Короче, дохрена их.

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

Выкладываешь свою скомпилированную срань и её влинковывают.

ему надо вызвать пару твоих функций, но их код он видеть не должен.

то есть ему мало скомпилированного кода. ему нужны заголовки функции еще.

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

Какая странная совместная разработка.

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

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

ему надо вызвать пару твоих функций, но их код он видеть не должен.

то есть ему мало скомпилированного кода. ему нужны заголовки функции еще.

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

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

Либо через трейт, либо через публичный крейт, который зовет кишки приватного.

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

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

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