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 ()

От себя: это жесть, товарищи, нам только COBOL не хватает для полного счастья.

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

Поставил минус так как вообще не понимаю почему до сих пор там нет поддержки с++, а какой то Rust пихают.

mx__ ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

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

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

Да Вы посмотрите на мессаги ВЫШЕ и дизлайки, думаете они понимают что такое С++ ?

mx__ ★★★★★
()

Поставил клоуна не автору новости, а сабжевой идее.

Logopeft ★★
()

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

(толксы не читал)

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

Рантайм жирный ещё.

В остальном да, текст на плюсах куда более читаем, чем на сишке. Одна работа со строками чего стоит (но это, скорее, актуально для прикладного программирования, не для ядра).

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

значительно продвинулись вперёд в своём развитии и язык C++ стал лучше, чем С, подходить для разработки ядра операционных систем

На этой фразе у сишников, от крайней степени возмущения, треснули черепа.

можно по частям переводить код с языка C, так как С-код можно компилировать как C++

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

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

неидеоматического недоC++ с отсутствующим ООП и сишным программированием в C++ коде.

А что в этом плохого?

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

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

У меня 120MB исходников проектов за две минуты компилируются и собираются.
Мог бы добиться того, чтобы и за 1 минуту компиляция и сборка выполнялась.

Проблемы возникают у ПРОДВИНУТЫХ, у которых код должен быть КРАСИВЫМ и СОВРЕМЕННЫМ.

Проще говоря - «Горе от ума».

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

но это, скорее, актуально для прикладного программирования, не для ядра

именно. Если тащить C++ в ядро, там надо отключать RTTI, исключения, выбрасывать стандартную библиотеку и STL, те же строки переписывать заново или брать готовое, независимое от стандартной библиотеки и контейнеров.

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

Вопрос не по теме, но почему ты постоянно удаляешь свои комментарии?

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

отключать RTTI, исключения

Да, как раз всё то, без чего оригинальный C++ от Страуструпа, он же «Си с классами» спокойно существовал несколько лет. И без шаблонной магии ещё :)))

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

У меня 120MB исходников проектов за две минуты компилируются и собираются.

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

Проблемы возникают у ПРОДВИНУТЫХ, у которых код должен быть КРАСИВЫМ и СОВРЕМЕННЫМ. Проще говоря - «Горе от ума».

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

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

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

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

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

Да, как раз всё то, без чего оригинальный C++ от Страуструпа, он же «Си с классами» спокойно существовал несколько лет. И без шаблонной магии ещё :)))

Весь цимес в шаблонах, в т.ч. вариадических, фолдинге, концептах.

seiken ★★★★★
()

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

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

А что в этом плохого?

намекает на незнание фич C++ и/или неумение их применять. Ведь если фичи не используются, нафига вообще брать C++?

seiken ★★★★★
()

И так я узнал, что они ещё не.

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

намекает на незнание фич C++ и/или неумение их применять.

Речь совсем не об этом была (не фантазируйте).

Forum0888
()

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

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

Если тащить C++ в ядро, там надо отключать RTTI, исключения, выбрасывать стандартную библиотеку и STL, те же строки переписывать заново или брать готовое, независимое от стандартной библиотеки и контейнеров.

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

atrus ★★★★★
()

Ну так-то он правильно говорит. Rust я уважаю, но объективно ядро на нём никогда не перепишут, а С++ внедрять вполне реально.

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

И без шаблонной магии ещё :)))

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

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

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

инкапсуляция, динамический полиморфизм, RAII, шаблоны, constexpr

seiken ★★★★★
()

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

Smacker ★★★★
()

только вот вы не учли что мозг разрабочтика ядр для ос уже давно раюотает только с C

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

Я не думаю, что кто-то в своём уме предлагает перевести ядро на полновесный С++ со всеми его фишками.

А так - сменить компилятор на g++, и очень аккуратно переводить те места, которые на С откровенно неудачно выглядят, на С++ - почему бы и нет.

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

В ядре ОС? Может я чего-то не понимаю…

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

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

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

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

У меня 120MB исходников проектов за две минуты компилируются и собираются.

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

Конечно ты можешь выставить меня идиотом предоставив вывод характеристик железа и время результаты времени сборки. =) Я на это надеюсь :D

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 3)

помимо нынешнего применения языка Си с ассемблерными вставками и продвижения языка Rust.

Как по мне, то наверняка, если в линух пихается тучи драйверов видюх и т.д., то первоочередная цель ядра - это потребитель, а не нормальная быстрая система.
Имеется ввиду что не ставится упор на использование linux предпочтительно в медицинском оборудовании.
А если так, то переписывание критических участков на C++ / Rust не сделают ровнм счётом ничего, если потом сверху будут наворачивать тормозной KDE / Gnome.
То есть, если высокоуровневый код принесёт штабильность и удобство поддержки, то я за.

xwicked ★★☆
()
Ответ на: комментарий от LINUX-ORG-RU

И при этом его пример всё равно ни о чём, даже на последнем риппере. Вот, AOSP на самом ядерастном и распоследнем АМД - 40 минут.

seiken ★★★★★
()

Давайте взглянем правде в глаза: C++ - это противоречивый и неудобный язык программирования, имеющий ровно 4 достоинства: совместимость с C, деструкторы, шлабоны и автоматически заполняемые vtable. Шлабоны несовместимы с другими языками, с тем же C, поэтому по большей части сразу не катят, деструкторы резко теряют привлекательность как только откажешься от неявных аллокаций, а заполнять vtable всё равно придется для совместимости с C. В итоге остаётся только совместимость с C, которая, внезапно, есть и у самого C. Соответственно зачем это всё?

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

Разве это не performance penalty?

Смотря относительно чего. Относительно прямого вызова косвенная адресация естественно медленнее.

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

Полиморфизм С++ относительно свелосипеженного руками performance penalty не содержит, скорее наоборот, в некоторых ситуациях, когда компилятор может провести девиртуализацию.

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

У плюсов есть главное преимущество над сишкой: строгая проверка типов и отсутствие необходимости в type erasure через void*.

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

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

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

Ivan_qrt ★★★★★
()

вы не понимаете
это другое

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