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)

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

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

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

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

Пример чего? Деструктора, освобождающего память? Ну ок:

~MyClass(){
   delete ptr;
}

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

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

Ведро, как почти любая сложная система, нуждается в механизме динамического вызова. И он реализован на языке C. Использование аналога из плюсов сомнительно: нужно либо сишную реализацию делать совместимой с плюсовой (а она, если не ошибаюсь, не документирована), либо иметь 2 несовместимые реализации одного и того же, одну для того что может вызываться извне, другую для внутреннего применения. Это создаст путаницу, которая не компенсируется небольшой пользой от наличия внутри плюсов встроенной реализации.

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

Речь вообще-то не о том что твоя любимка - говно, а о том, оправдано ли включение плюсов в ядро. В уже существующий проект написанный на C. Речь не о переписывании всего на плюсы. В таких условиях самые вкусные черты плюсов окажутся неиспользуемыми, останутся только C с классами. А имеет ли это всё хоть какой-то смысл? Ну явно нет.

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

Не надо паники, буст и прочее никто добавлять не будет. Исходники gcc перевели с си на с++ и ничего страшного не произошло.

windprop2
()

у С++ всегда будет проблема утверждения, что это не С с классами.

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

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

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

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

Сам по себе unique_ptr не нужен, он ценен как член некоей структуры.

Создать ресурс где-то в произвольной точке функции и гарантированно его освободить, без возни с goto final и ручной очистки и без нестандартных расширений - это не нужен? Ты из свято верующих в собственную непогрешимость?

А код драйвера не так уж обычно сложен, чтоб реально выигрывать что-то на плюсах

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

особенно с «рантаймом».

Какой такой рантайм ты тут нашёл, которого нет в сишке?

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

так как дублирует уже существующую фичу, которую удалить нельзя.

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

Речь не о переписывании всего на плюсы. В таких условиях самые вкусные черты плюсов окажутся неиспользуемыми, останутся только C с классами. А имеет ли это всё хоть какой-то смысл? Ну явно нет.

На деле имеет. Даже если примут минимальный вариант плюсов даже без плюсового манглинга всё равно останется более строгая система типов. Это позволит избавляться от void* и дрисни на макросах. Да, происходить это будет не быстро, в каких-то кусках останется навсегда, но там, где идёт активная работа или где выявляются ошибки код будет улучшаться. Одного этого уже достаточно.

Ivan_qrt ★★★★★
()

Это какая-то языковая дискриминация! Почему только Сишечка, Ассемблер и Rust?! Почему нельзя использовать Java, Python, JS и Brainfuck?!

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

Офигительно он читаем.

template < class T >
class std::enable_if< Some_struct, std::is_fundamental<T> > :: type
{
};

И это классический прием, без всяких хаков.

А можно, например, переопределить operator,() как в Boost assign для инициализации контейнеров:

std::vector < int > my_vec;
my_vec += 1,2,3,4,5;

И это все работает в C++98, а знаете что можно написать в более поздних стандартах?

Ядру после этого окончательный трындец. Там даже в сишном коде черт ногу сломит, что будет, когда там будет C++?

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

Нет рантайма, если не использовать RTTI (dynamic_cast).

zx_gamer ★★★
() автор топика

Ребят, это вообще нормально, что я ничего не понимаю из того, что вы тут пишете? А ведь у меня пять звёзд … [facepalm.gif]

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

Вот. Умные мысли всегда радуют.

(с крестами это произошло после внедрения многопоточности?)

Окончательное, наверное, да. Но даже C++98 хорошо так сел на STL и выкорчёвывание его стоит хоть и не катастрофических, но не нулевых усилий.

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

Да, где-то в толксах была, говорят.

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

знаете что можно написать в более поздних стандартах?

В более поздних стандартах код гораздо более читаемый, и от sfinae тоже ушли.

AntonI ★★★★★
()
Ответ на: комментарий от sparkie
Били копыта. Пели будто:
— Гриб.
Грабь.
Гроб.
Груб. — 

Угробят ядро, в этом уже нет никаких сомнений.

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

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

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

Офигительно он читаем.

Да:

template <class T>    
concept Fundamental = std::is_fundamental_v<T>;    
    
template <Fundamental T>    
struct Struct {    
    T t;    
};    

Явно лучше, чем

void func(void* arg1, void* arg2, void* arg3) {
}

а знаете что можно написать в более поздних стандартах?

Учитывая, что в сишке можно написать #define true false абсолютно не важно, что можно написать на плюсах. И один и другой язык позволяют написать лютой забористой херни, и люди так делают.

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

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

и от sfinae тоже ушли

Это неправда. Библиотеки, как правило совместимы даже с C++98, поэтому там ничего нового нет и не будет.

В более поздних стандартах код гораздо более читаемый

Не надо рассказывать сказки. Стандарт вырос еще на две пачки бумаги в толщину. Можете открыть https://cppquiz.org и наглядно убедиться, насколько «очевидный» код в C++17. И он никогда не сравнится с Си по простоте.

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

Хотя нет, рантайм еще есть при использовании виртуальности, но он почти нулевой.

С чего вдруг это рантайм? А вручную свелосипеженный vtable на сишке это тоже рантайм?

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

Библиотеки, как правило совместимы даже с C++98, поэтому там ничего нового нет и не будет.

Откройте уже доки и посмотрите сколько новых методов появляется с каждым новым стандартом в STL.

Не надо рассказывать сказки

До до

for(blabla::iterator I=C.begin(); I!=C.end(); ++I)...

for(auto I=C.begin(); I!=C.end(); ++I)...

for(auto I: C)...
AntonI ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Раст монстр только кажущийся. Как показала одна статья на Хабре(понимаю что кто-то на этот ресурс неровно дышит), там можно вполне себе достичь минимализма сишечки, т.е. отрубить всё и вся.

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

Впрочем в случае плюсов тоже не вижу в них смысла в ядре. По сути будет та же сишечка, вид сбоку.

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

Если тащить C++ в ядро, там надо отключать RTTI,

+1

исключения,

+1 (хотя я их и люблю)

выбрасывать стандартную библиотеку и STL,

+1

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

Строки тоже выбрасывать. Сишные строки на стеке вполне себе рулят. Разве что 0-terminated можно было бы подумать заменить на что-то типа std::string_view, но учитывая что они торчат наружу в API, смысла в этом примерно 0.

А вот откуда тут взялись некоторые, топящие за выкидывание ООП – зогатко природы. Видимо там, откуда они вылезли, модно вручную vtables эмулировать.

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

Корневой конфиг nginx объявлен ЕМНИП как void****. Вот блин меня разорвало. В итоге так и не разобрался до конца, что-то методом тыка по сорцам наскрёб, чтобы заработало то, что мне нужно.

Вообще, void* это по сути банальная динамическая типизация. Нечитабельный и непроверяемый компилятором полиморфизм. Говно собачье, в общем. А другого полиморфизма в сях у меня для вас нет: его там вообще нет. (Ну разве что можно указатель на функцию в другую функцию передать. А два указателя на две функции – дык это уже ООП-интерфейс.) Вот и пердолятся убогие, и в своём убожестве поливают говном язык, где он есть. На плюсях я бы нарисовал иерархию классов, может даже без виртуальных методов – т.е. без vtable, с нулевым рантайм-оверхедом, чисто ради читабельности – и вместо void* написал бы BaseClass*. Ну и кастовал бы через static_cast. Ещё и покомпактней рантайм бы вышел, с такой-то информацией у компилятора.

Во, точняк:

struct ngx_cycle_s {
    void                  ****conf_ctx;

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

Деды на Си писали и городили ООП на чистом Си,

Деды и зад подорожником вытерали, но ты же так не делаешь? Надеюсь...

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

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

Вы же не думаете, что они тратят время на майнинг биткойна?

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

Деды и зад подорожником вытерали, но ты же так не делаешь?

Со спущенными штанами сложно найти подорожник в наше время. Особенно в центре города.

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

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

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

Ядро настолько прибито к gnu тулчейну, что вряд ли реализация нужных фич для c++ будет проблемой, всё равно компиляторы будут ограничиваться gcc и мимикрирующим под него clang.
Rust создаёт куда больше сложностей, но даже там достаточно наличия порта llvm под таргет по идее

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

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

RAII без исключений смысла не имеет. Точнее, невозможен.

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

Шутка

Как пpовожают C++
Совсем не так как Си

Си бурливые воды
Hе то что template в два pяда

Как ни суди волнений больше
Ведь ты уже не на земле

Как ни pяди pазлука дольше
Когда плывешь на C++ в никуда

Флуд флуд кpугом вода
Вода вода шумит вода
Forum0888
()
Ответ на: комментарий от zx_gamer

Хоть массово увидят люди.

Шутка

Ага, выйдут на демонстрацию с транспорантами «Не дадим в обиду C++», ...

Товарищи флудильщики! "Физики" с кандидатами!
Замучились вы с иксами, запутались в C++!

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

Из гнили да из template бальзам извлечь пытаетесь
И флудите в тредах по десять раз на дню.

Ох, вы там дофлудитесь! Ох, вы довыпендриваетесь,
Пока сгниет, заплесневет картофель на корню!

Автобусом до Сходни доезжаем,
А там — рысцой, и не стонать!
Небось Си все вы уважаете,
Когда с сольцой его намять!

Вы можете прославиться почти на всю Европу, коль
С транспорантами в треде проявите свой патриотизм.

А то вы всем кагалом там набросились на Си,
Rust ножами режете, а это — бандитизм.

Автобусом к Тамбову подъезжаем,
А там — рысцой, и не стонать!
Небось Си все вы уважаете,
Когда с сольцой его намять!

Товарищи ученые, флудильщики драгоценные,
"Физики" ненаглядные, любимые до слез!

Ведь лягут в землю общую остатки наши бренные,
Core Linux все едино: апатиты и навоз.

Так приезжайте, милые, рядами и колоннами.
Хотя вы в форуме все там ФИЗИКИ и нет на вас КРЕСТА,
Но вы ж треде все задохнетесь, за флудом, -
А здесь места отличные, воздушные места!

Товарищи ученые! Не сумневайтесь, милые:
Коль что у вас не ладится — ну, там, не тот аффект, -
Мы мигом к вам заявимся с лопатами и с вилами,
Денечек покумекаем — и выправим дефект.
Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 12)
Ответ на: комментарий от dimgel

RAII это не про конструктор, а про деструктор. Буквально первоочередное назначение RAII это избавиться от костылей вроде goto final и от любого другого ручного управления памятью.

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

Ну а конструктор и выделение памяти при отсутствии исключений как таковое не меняется. Выделил - проверь, что выделилось. Тот же код, что и в сишке.

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

Использую Visual Studio 2013 и non promlem при разработке API.

«Бальзам» из стандартов C++ всё время извлечь пытаются, забыв, что рулит всем алгоритм.

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

Берите, что хотите.
Главное не забывайте, что рулит всем алгоритм, а не «надувание щёк стандартами».

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

Меня-таки как раз исключения в конструкторе интересуют. Например, при открытии файла. С деструктором наоборот всё понятно: он noexcept. А если вместо исключения нужен отдельный init, возвращающий ошибку, то как минимум возникает вопрос: а компилятор (LTO) достаточно умён, чтобы увидеть, что после конструктора ВСЕГДА вызывается init, и удалить код инициализации полей по умолчанию? А как максимум, RAII расшифровывается не про деструктор. :)

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

Не то что новомодная ржа: ни ООП, ни исключений. Ваше замечание будет актуально лет (десятилетий? веков?) через даже не знаю сколько, на выходе из надвигающихся тёмных веков. А нынешние хипстеры один хрен ничего стоящего родить не смогут.

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

Звёзды – это про флудерастию, а не про понимание ЯП каменного века.

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