LINUX.ORG.RU

Дискуссия об использовании языка C++ для разработки ядра Linux

 ,


1

5

В списке рассылки разработчиков ядра Linux возобновилось начатое шесть лет назад обсуждение перспектив использования современного кода на C++ в ядре Linux, помимо нынешнего применения языка Си с ассемблерными вставками и продвижения языка Rust. Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра.

С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков ядра в компании Intel и создатель таких проектов как syslinux, klibc и LANANA, разработавший для ядра Linux систему автомонтирования, реализацию RAID 6, драйвер CPUID и x32 ABI. По мнению Анвина, который является автором многочисленных макросов и ассемблерных вставок в ядре, с 1999 года языки C и C++ значительно продвинулись вперёд в своём развитии и язык C++ стал лучше, чем С, подходить для разработки ядра операционных систем.

Возможности, для которых ещё недавно приходилось привлекать специфичные GCC-расширения, теперь легко реализовать на стандартном C++, и во многих случаях использование C++ позволит улучшить инфраструктуру без глобального изменения кода. В качестве минимальной упоминается использование спецификации C++14, которая включает необходимые средства метапрограммирования, а в качестве желаемой - использование спецификации C++20, в которой появилась поддержка концепций, способных исключить появление многих ошибок.

Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat.

>>> Подробности

★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)

Ответ на: комментарий от ad0c

Любая достаточно сложная программа на Си или Фортране содержит заново велосипеды

Всё так.

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

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

движок от трактора не влезит в мою «Оку», так что нафиг эти трактора нужны?!

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

чего? Пример в студию!

а заполнять vtable всё равно придется для совместимости с C

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

В итоге остаётся только совместимость с C, которая, внезапно, есть и у самого C

нет, в итоге остаётся очень толстый наброс от тебя

seiken ★★★★★
()

Еретики, на костер их. Деды на Си писали и городили ООП на чистом Си, и нам завещали. А эти что удумали, легкие пути в жизни ищут.

mbivanyuk ★★★★★
()

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

Bad_ptr ★★★★★
()
Последнее исправление: Bad_ptr (всего исправлений: 1)

А я всю жизнь думал что ядро на с/с++ пишут а оказывается только на c. Пора новую криокамеру покупать, старая протекла.

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

Какие параметры по-твоему содержат эти абстрактные «машины», подразумеваемые стандартами современных языков?

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

Так деды топором брились! И чо нам теперь? :)

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

С чего бы его выкинули? Наоборот, новых труднопонимаемых смыслов навешали :)

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

С некоторой его эмуляцией. Оно и в С++ на процедурах, просто есть куча синтаксического сахара.

gns ★★★★★
()

В целом я идею поддерживаю, но только при условии нормального code review и наличия гайдов конкретно для ядра.

Проблема С++ в том, что одну и ту же задачу можно реализовать 100500 способами (намного больше чем в C), и каждый способ имеет свои достоинства и недостатки. И ты обязан знать эти способы и их особенности чтобы выбрать правильный. Плюс есть другие вещи, которые ты должен держать в голове, например, правила exception safety. Ошибешься пару раз, и запишешься в секту хейтеров C++. То есть если коротко проблема С++ - высокий порог входа.

Ну, и еще реальные проблемы C++ (не кудахтанье на форумах) описаны в The Dark Side of C++.

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

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

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

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

Вот только этого нам не хватает. :)

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

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

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

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

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

Ну ты хоть раз-то посмотри на чем работаешь. Ты не поверишь, весь код открыт :)

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

Но как ты сделаешь прямой вызов, если тебе становится известен адрес вызова только в рантайме?

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

Я это спрашиваю, потому что именно ДП я видел только в классах Animal и Shape в учебниках. На практике мало того, что к херам вся эта галиматья идет, а тут ее еще и в ядро притащили o_O

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

C++ выкинули volatile

Таких параметров нет, потому что volatile из плюсов не выкидывали.

Ivan_qrt ★★★★★
()

Ни кресты, ни тем более этот ваш руст в ядре не нужны.

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

exception safety

да не будет в ядре ексепшенов, хотя кто знает

Мы говорим о безопасном коде и исключаем один из ключевых инструментов для этого? Ну-ну…

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 1)

возобновилось начатое шесть лет назад обсуждение

Если звёзды загораются, значит это кому-нибудь нужно.©

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

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

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

в каких ситуациях такое возможно

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

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

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

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

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

В любом случае, когда есть стандартный интерфейс (например для ФС: читать, писать и проч.) и различные реализации одного и того же интерфейса. Например, для ext4 пишем в блочное устройство, а для NFS отправляем в сеть. Это стандартная ситуация, не важно, ООП явно поддержано в ЯП или костылится вручную.

На практике мало того, что к херам вся эта галиматья

На практике - это чуть менее, чем везде.

seiken ★★★★★
()
Последнее исправление: seiken (всего исправлений: 1)

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

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

Нет дружище, в форуме всегда говорю лишь правду.

вы эту фразу правили 5 раз... :о)
абсолютно с вами согласен, сам люблю править все, переправить... :о)

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

а ведь действительно, ядро уже сейчас собирается до неприличия долго и нудно... таки шо будет после?! - а сплошная дискотека! :о)

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

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

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

Исправления были в удалённых строках.

Скажу Вам по секрету - «Жаренная картошка с лучком и томатным соком, много полезнее споров ни о чём».

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 2)

Концепты работают уже? Если да, то нужно

buddhist ★★★★★
()

вопрос ко всем, многоуважаемым донам!
почему «в таком случае» не создаются ответвления от основной ветки ядра?! как говорится, отчипилисья и делайте что хотите, хоть на голове ходите, ибо нефиг в колодец плявать?! и линус счастлив и все остальные ... бесы сыты :о)

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

И чтобы весь зоопарк API поддерживать, драйвера будут в «системнонезависимом» стиле, когда они с собой всю мини-ОС реализовывают, делая прослойки для работы с памятью, DMA, и прочей мелочью под всяко разные ОС. Обычно так реализовывают всяко разные закрытые драйвера на подобии Rogue. Я даже не буду писать чем это все грозит.

maxis11
()

Мне кажется, что раст необходимо выкинуть окончательно, пока ещё не много подсистем на нем написано! Ядро должно компилироваться одним набором компиляции! C++ действительно поможет избавится от многих проблем по типу переполнения буфера благодаря богатой системе абстрагирования кода! Также никто не мешает включить bound check для защиты. Главное отключить динамическое выведение типов и исключения и асе будет работать ещё лучше! Можно будет избавится от void* и обеспечить более строгую компиляцию, а значит сделает потенциально сложнее допущение ошибок в типах данных. Тем одинаковые алгоритмы на на C++ быстрее, чем на Rust. Тем более между C++ и C можно обеспечить практически безболезненную совместимость!

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

Ну у тебя есть десяток форков GNU/Linux с разными API под разные ЯП. Как производители SoC’ов(или просто устройств) это все поддерживать будут? Примерно выше и написал как (если вообще будут).

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

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

(это я, коненчо, стебусь, еслиф что... но, в каждой шутке...)

ну а как, например, стыкуются pascal & c? берутся хедеры, переводятся в pascal итд итп...

sunjob ★★★★
()
Последнее исправление: sunjob (всего исправлений: 1)

Потом они захотят туда и буст. Они же без него никуда – С++ недостаточно развитый язык. Хотя, после добавления раста, ящик Пандоры открыт.

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

Во-первых, зачем отказываться от неявных аллокаций?

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

Во-вторых, чем они теряют привлекательность? unique_ptr бесполезен по-твоему?

Без неявных аллокаций? Да.

Вообще, он малополезен по другой причине. Сам по себе unique_ptr не нужен, он ценен как член некоей структуры. А как ты будешь пользовать эту структуру вне C++ кода? Никак. Значит, это чисто для кода внутри компонента, например драйвера. А код драйвера не так уж обычно сложен, чтоб реально выигрывать что-то на плюсах, особенно с «рантаймом».

khrundel ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.