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 ★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Врёшь за 120 секунд и собрать и слинковать всё… или собираешь

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

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 5)
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от sparkie

Нет, это настоящий ++C+++++ ... (чем плюсов больше, тем ЯП лупше).

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

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

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

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

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

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

Ещё один очевиднейший пример - LSM.

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

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

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

Жалобщик:

Плохому программисту всегда ЯП мешает.

if ( flЖалобщик )
goto Жалобщик;

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 5)
Ответ на: комментарий от 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 ★★★★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.