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

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

а то ситуация похожа на захват жизненного пространства, сами знаете кем. места мало что-ли?

Они всё равно его захватят, скорее всего просто форкнув ядро со временем. Старое поколение стареет и начинает уходить. Продолжать разработку старыми методологиями и инструментами будет просто некому. По крайней мере в прежнем объёме. Корпорации переключатся на форк и перестанут поддерживать оригинальное ядро. Без корпораций любой проект такого уровня просте нежизнеспособен. А без достаточного количества людей, способных и интересующихся копанием в технологиях 80-х - тем более.

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

Они всё равно его захватят, скорее всего просто форкнув ядро со временем. Старое поколение стареет и начинает уходить. Продолжать разработку старыми методологиями и инструментами будет просто некому. По крайней мере в прежнем объёме.

Они его уже давно захватили. Ядром владеет Linux Foundation, LF контролируется микрософтом сотоварищи.

Корпорации переключатся на форк и перестанут поддерживать оригинальное ядро.

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

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

поколению инклузивных зуммеров

так а всё уж, вроде, отмена, не? )) блондинчик уже подписал какие-то указы 🤭

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

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

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

по этой причине на русте не будет написано ничего большого и серьезного. потому что большое и серьезное на хайпе не пишут.

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

Они его уже давно захватили. Ядром владеет Linux Foundation, LF контролируется микрософтом сотоварищи.

Линус ещё держит всех за яйца.

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

Вот цитата из более подробной новости на Опеннете:

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

Отказ принимать код обвязки над вызовами DMA поставил разработчиков проекта Rust for Linux в тупик, так как без подобных обвязок разработка полноценных драйверов на языке Rust будет затруднена. Гектор Мартин (Hector Martin), мэйнтейнер кода для поддержи ARM-чипов Apple и лидер проекта Asahi Linux, в качестве варианта разрешения конфликта предложил добиться принятия обвязки напрямую через Линуса Торвальдса, в обход сопровождающего подсистему DMA. Если Линус согласится на подобное нарушение субординации и сложившейся практики, это может привести к кризису управления разработкой ядра, а если откажется - остановит продвижение Rust в ядро.

Тут CoC даже не пахнет. Тут явно назревает бунт, обиды, хлопанье дверьми и форки. Если Торвальд откажет, то весьма вероятно появление форка ядра. Судя по истории с прошлым отказов «pull-запроса с изменениями в подсистеме управления памятью» новый отказ вполне вероятен, со всеми вытекающими из него последствиями. Короче, ждите историю, напоминающую появление OpenBSD.

zg
()

Линус: попробуем привлекать новых разработчиков на расте к разработке ядра

Лоровцы: вы кто такие? Мы вас сюда не звали!

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

Они его уже давно захватили. Ядром владеет Linux Foundation, LF контролируется микрософтом сотоварищи.

Линус ещё держит всех за яйца.

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

Тут CoC даже не пахнет. Тут явно назревает бунт, обиды, хлопанье дверьми и форки.

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

Если Торвальд откажет, то весьма вероятно появление форка ядра. Судя по истории с прошлым отказов «pull-запроса с изменениями в подсистеме управления памятью» новый отказ вполне вероятен, со всеми вытекающими из него последствиями.

Ставлю 100 баксов, что в ближайшие три года форка не будет.

Короче, ждите историю, напоминающую появление OpenBSD.

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

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

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

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

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

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

Ну не так уж и мало, на самом деле. К тому же им позволили таки влезть в ядро, немного там покопаться и набрать опыта. Rust популярен у корпораций и у госов, которые его продвигают уже несколько лет вполне официально. Поэтому если дойдёт до форка, они поддержат как раз таки бунтарей. А Торвальдс и компания будет новым поколением пенсионеров-Столлманов, читающих лекции про швабодку и вот это всё. Их просто лишать финансирования. Не сразу конечно, но в случае форка - обязательно.

по этой причине на русте не будет написано ничего большого и серьезного. потому что большое и серьезное на хайпе не пишут.

Ты слишком категоричен.

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

Если Торвальд откажет, то весьма вероятно появление форка ядра.

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

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

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

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

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

Хм. А что правда rust позволяет программировать не зная архитектуру?

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

Линус ещё держит всех за яйца.

Судя по ситуации скорее наоборот.

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

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

Куда именно его уходили? Он как был единственным владельцем торговой марки, так им всегда и оставался. На сколько я знаю не было ни одного релиза ядра без его одобрения. По крайней мере мажорного релиза.

Ставлю 100 баксов, что в ближайшие три года форка не будет.

Ну не обязательно через три, может быть и через 5 и через 10. Торвальдсу сейчас 55 лет, сколько он ещё сможет тянуть этот проект и сколько ещё его когнитивные способности будут соответствовать лидеру проекта? Вон Столлман, в своё время, замахнулся на целую операционную систему, но так и не смог довести её до ума. В результате GNU стала подстилкой Linux и уже никогда не превратится в полноценную ОС, каковой она задумывалась изначально.

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

Это не так. Абстракции гарантируют некоторый контракт, который в C гарантируется исключительно тестированием, страданием и багрепортами.

Нет, это так, дополнительный слой абстракции ВСЕГДА ведет к усложнению т.к это не что иное как сокрытие деталей реализации через некоторый контракт. Абстракция делает хорошо на этапе использования ПО, а не в разработке. Это база системной архитектуры.

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

Страдать с сишными багами не менее трудозатратная работа.

Так а куда денутся сишные баги если часть кода переписать на расте? К сишным багам добавятся баги раста и увеличиться сложность разработки из-за дополнительного слоя абстракции.

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

Кто ж им мешает? Пусть запилят альтернативную реализацию какого-нибудь модуля.

Никто не мешает. Запилии и альтернативу, и новые.

Так может для начала никуда ничего не тащить, сделать это частью драйвера/модуля? Именно это и предлагается же.

Предлагается делать общую абстракцию, которая уже нужна каким-то нескольким проектам. Причем это абстракция не является частью kernel/dma, она является её потребителем.

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

Так а куда денутся сишные баги если часть кода переписать на расте? К сишным багам добавятся баги раста и увеличиться сложность разработки из-за дополнительного слоя абстракции.

Сишные баги не появятся в новых драйверах.

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

Нет, это так, дополнительный слой абстракции ВСЕГДА ведет к усложнению т.к это не что иное как сокрытие деталей реализации через некоторый контракт. Абстракция делает хорошо на этапе использования ПО, а не в разработке. Это база системной архитектуры.

Это все вообще не имеет никакого отношения к происходящему. Абстракция уже существует – тот самый DMA allocator, для которого биндинги принесли. Просто в растовых биндингах контракт зашит в API функций (потому что система типов позволяет), а в C оно зашито в коллективное бессознательно реализующих драйверы. API тот же самый.

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

Зато появятся растовые + баги абстракции, хорошо описанные вот в этом посте.

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

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

Это все вообще не имеет никакого отношения к происходящему.

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

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

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

Это все тоже не имеет отношения к происходящему:

But a generic «hey, this broke our working toolchain builds» is something that is much much much different than «an api changed so I now have to turn off this driver in my build» issue.

Читайте что ли переписки полностью.

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

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

А проблема-то где? В этом случае мейнтейнеры rust/ получают обезьянку в виду все починить.

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

Так а куда денутся сишные баги если часть кода переписать на расте?

Останутся в той части кода, которая всё ещё написана на Си.

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

Какие баги Раста? Разве в Расте есть такое количество UB, как в Си? Или Раст позволяет работать с памятью так же опасно, как в Си? Да, Раст отпугивает дополнительной сложностью из-за borrow checking и немного инопланетным синтаксисом. Это как раз и разделяет поколения разработчиков. Но принципиальным барьером, не позволяющим, со временем, переписать большую часть ядра на Раст, это не является.

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

Да или нет? В глаза смотреть! :)

Жёлтые штаны - два раза ку!

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

Зато появятся растовые + баги абстракции, хорошо описанные

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

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

рустовики успешно поломали процесс разработки кода, от них не зависящего

говорит и о русте, и их квалификации

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

Так это сишники тогда не осилили, получается. Почему проблема в коде на расте ломает им весь проект? Почему они не сделали раст где-то сбоку, и если что-то на расте не работает - чтоб ломался только этот компонент, но никак не мешал сборке\работе сишного кода?

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

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

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

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

Вот это мне не понятно, Линус же сказал типа «добавляю раст в ядро», значит раз он руководит разработкой и последнее слово за ним то после такого заявления не должно быть уже никаких «договоров» с мейнтейнерами. Тут же не пожелание сделать что-то иначе (судя по новости), а в целом нежелание взаимодействовать с кодом на расте.

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

Или Раст позволяет работать с памятью так же опасно, как в Си?

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

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

Линус отдает себе отчет в том что ядро пишет не он, а отдельные команды людей, которыми хоть как-то пытаются руководить мейнтейнеры. И все это это пребывает в относительном равновесии. Чтобы внести в это все второй язык нужно ОЧЕНЬ много психотерапии в обе стороны, поэтому Линус поступил достаточно мудро – несите туда, куда несется, а туда куда не несется – не несите, пока там не наступит понимание, что это от принесенного пользы больше, чем проблем.

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

Пусть тогда дорабатывают компилятор, чтобы использовал структуры языка «C».

Так они сами зависят от компилятора.

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

если часть кода переписать на расте? … и увеличиться сложность разработки

Ещё в разы уменьшится скорость компиляции.

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

Ты уверен, что понимаешь написанное?

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

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

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

Ещё в разы уменьшится скорость компиляции.

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

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

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

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

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

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

А ещё он убивает время компиляции.

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

и на первом месте там читаемый синтаксис и точное понимание того, что происходит

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

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

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

Ничего?

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

А ещё с линкером, GCC, clang и LLVM. И ещё с тем что код, который на x86_64 собирается, внезапно через три дня присылает тебе ататат от kernel test robot. Вот вообще ничего нового.

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

Так это сишники тогда не осилили, получается. Почему они не сделали раст где-то сбоку, и если что-то на расте не работает - чтоб ломался только этот компонент, но никак не мешал сборке\работе сишного кода?

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

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

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

А ещё он убивает время компиляции.

Ваще пофиг, все ядро обмазано макросами с ног до головы. Ты даже простейшего модуля без них не напишешь. Буквально.

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

Но костыли действительно чудовищные, делающие код совершенно нечитаемым для любого, недостаточно надрочившегося в эти ваши макросы. Фактически это ещё один ЯП внутри Си.

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

На Расте полно ядер. Они на нём за день пишутся новичком.

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

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

С такими раскладами можно и PHP-макак в код ядра пускать. А что, у нас и совместимость с С полная.

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

прибежит питон, паскаль, ди, голанг, джава, и все прочие сироты

А мне за уже упомянутый zig, а ещё crystal, nim, odin, red, pony, C3, Beef обидно. А там ещё гляди и webasm.

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

ты вот сейчас буквально раст описал, и синтаксис более читаемый, особенно по сравнению с плюсами;

Это что троллинг такой? По моему все даже, растаманы соглашаются что синтаксис у rust самый дебильный.

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