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)

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

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

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

А причём тут Go? Во-первых, там есть GC. Во-вторых, на нём не пишут код, для которого критично качество оптимизации со стороны компилятора. Чтобы в С++ с включенными исключения не запарывалась производительность, нужно по полной обмазываться noexcept, что как бы убивает смысл использования исключений.

annulen ★★★★★
()
Ответ на: комментарий от annulen
  1. Насколько я слышал, нынешние исключения – zero cost, используют изолированные от основного кода структуры для раскрутки стека. Хм, т.е. green path может быть даже БЫСТРЕЕ, чем проверки результатов в каждой строчке. Лень прикладнушника всегда мешала мне детально разобраться в том, как устроена раскрутка стека. Но твой пассаж про обмазывание noexcept звучит весьма сомнительно

  2. А твой предыдущий камень был вообще слишком обобщённый и категоричный. Отсюда и реакция.

Блин, задрало в телефон тыкать. Как молодёжи только не лень так общаться?

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

Как молодёжи только не лень так общаться?

Когда мыслей только на твит хватает, то какие проблемы)

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

Насколько я слышал, нынешние исключения – zero cost

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

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

Меня-таки как раз исключения в конструкторе интересуют. Например, при открытии файла.

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

  • Можно проверять, выделилась ли память в объекте после вызова конструктора (тут нужно добавлять проверку в деструкторе, но на производительности это не отразится буквально никак на фоне вызова free() или close()).
  • Можно заранее выделять ресурсы и явно передавать их в RAII-объект после проверки.
  • Можно std::expected возвращать из static-метода.
  • Можно, конечно, и init() вызывать, но имхо это худший вариант.

В любом случае мы получаем вариант проверок не хуже сишного и автоматическую очистку. За базовый вариант можно брать выделение ресурса в обычный указатель/переменную, проверку, оборачивание в unique_ptr.

удалить код инициализации полей по умолчанию?

Я так подозреваю, что это от init() зависит, если он не заинлайнится, то вряд ли. Но на фоне вызовов аллокатора или open() это всё буквально никак не отразится на производительности. Это запись нескольких байт в одной кэш-линии, причём уже подтянутой, а скорее даже запись нескольких регистров. Несколько тактов vs тысячи тактов в ожидании синхронизации.

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

Зирокост это здорово, а кто мне потерянные инлайны вернёт и т.п.?

Каким образом исключения мешают инлайнам?

Ivan_qrt ★★★★★
()
Ответ на: комментарий от annulen
  1. А Go при том, что в него исключения таки-добавляли. Вопреки тому, что мне тут некоторые чуть выше втирали. А вот при чём его GC – непонятно. Твой камент, на который я отвечал, был, повторюсь, слишком обобщённый и категоричный.
dimgel ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

И флаг им в руки. Закон сохранения сложности никто не отменял. Упрощаешь используемый инструментарий – усложняешь собственное приложение.

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

Вернусь домой – надо не забыть добавить тебя в игнор.

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

Упрощаешь используемый инструментарий – усложняешь собственное приложение

Года четыре назад разработал парсер конфигураций для 1С 7.7 (несколько тысяч строк).

Через какое-то время разработал новый алгоритм (у меня API позволяет вести разработку обобщённых алгоритмов).
Где-то 500 строк однако.

И знаете -«не усложнил собственное приложение».

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

Мои посты в треде в основном о том, что РУЛЯТ АЛГОРИТМЫ, а не стандарты.

Не обижайся, но твои посты в треде в основном БЕССМЫСЛЕННЫ.

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

А вот при чём его GC – непонятно.

При том, что исключения без GC == лёгкий способ получить утечку памяти в неожиданном месте.

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

Так и вы не обижайтесь.
Мнение аналогичное вашему о ваших постах - ТРЁП и не более того.

Впрочем проблема в том, что скорее всего вы не понимаете о чём посты (но щёки определённо умеете надувать).

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

Ребят, чисто ИМХО. Тот кто говорит, что исключения не нужны, тот просто не писал достаточно сложных программ для этого. До этого надо дорасти, там и понятно становится для чего на самом деле нужен noexcept (нет, это не про проиводительсность).

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

Ребят, это вообще нормально, что я ничего не понимаю из того, что вы тут пишете?

нормально, они сами тоже не понимают

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

Каким образом исключения мешают инлайнам?

Это надо у разрабов GCC спрашивать. Я вижу по дизасму, что код без -fno-exceptions гонвнякается, и мне этого достаточно.

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

При том, что исключения без GC == лёгкий способ получить утечку памяти в неожиданном месте.

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

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

Я вижу по дизасму, что код без -fno-exceptions гонвнякается, и мне этого достаточно.

Это речь про код, который может бросать исключения, или про код в котором вообще нигде нет источников исключений? Я к тому, что -fno-exceptions, насколько я понимаю, заменяет все возможные исключения на условный abort(). В таком случае понятно, что код может стать лучше, вопрос лишь цены.

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

Дружище, если уж быть честным, то из ваших постов и других разработчиков беру полезное - ЭТО ГЛАВНОЕ!

Видите ли у меня всегда так.

Где просто, там ангелов со ста. Где мудрено, там ни одного.

Стандарты ныне - МУДРЁННЫЕ.

Впрочем, ИМХО главное РЕЗУЛЬТАТ.
А он есть - ЭТО ГЛАВНОЕ.

Впрочем не претендую на то, что априори прав во всём.
Просто у меня так.

Да и бахвальства ИМХО нет, так как говорю о том, что уже разработано, да и в продакшен используется.
Всё ok!

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

Это речь про код, который может бросать исключения, или про код в котором вообще нигде нет источников исключений? Я к тому, что -fno-exceptions, насколько я понимаю, заменяет все возможные исключения на условный abort().

Нет, конечно. Код, бросающий исключения, с -fno-exceptions даёт ошибку компиляции.

annulen ★★★★★
()
Ответ на: комментарий от annulen
#include <iostream>

int* foo() {
        return new int[9223372036854775000 / sizeof(int)];
}

int main() {
        int* ptr = foo();
        std::string msg{"Hello world!"};
        std::cout << msg << ptr[10] << std::endl;
        delete[] ptr;
}
$ g++ -std=c++20 -O3 -fno-exceptions /tmp/test.cpp -o /tmp/test && /tmp/test
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Аварийный останов (образ памяти сброшен на диск)
Ivan_qrt ★★★★★
()
Последнее исправление: Ivan_qrt (всего исправлений: 1)
Ответ на: комментарий от Ivan_qrt

Пост не Ваш счёт.

Улыбнуло.
УМЕЮТ ребята - «УМЕЮТ»!

Супер!

Кстати Ваш пост напомнил о том, что нужно добавить API, умеющее эффективно работать с большими числами (не приоритетно, но пожалуй не помешает).

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

Я не уверен, с -fno-exceptions дел не имел, но насколько я понимаю, код с -fno-exceptions спокойно линкуется с бросающим кодом.

Т.о. сравнивать бинарь, собранный с -fno-exceptions с бинарём, собранным без него (-fexceptions) можно только в том случае, если не используется никаких бросающих библиотек (в том числе стандартной stl) или вызовов. И я сильно сомневаюсь, что -fno-exceptions в этом случае на что-то повлияет.

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

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

В реальных проектах с RAII и всеми best practices даже без исключений находят утечки из-за ошибок в логике. С исключениями всё ещё сложнее из-за появления неявных путей выполнения.

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

Я не уверен, с -fno-exceptions дел не имел, но насколько я понимаю, код с -fno-exceptions спокойно линкуется с бросающим кодом.

Да.

Т.о. сравнивать бинарь, собранный с -fno-exceptions с бинарём, собранным без него (-fexceptions) можно только в том случае, если не используется никаких бросающих библиотек (в том числе стандартной stl) или вызовов

Почему? Опция -fno-exceptions влияет на компиляцию единицы трансляции. Что происходит в слинкованном коде ей неведомо. Если оттуда вылетит исключение, то да, будет плохо.

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

С исключениями всё ещё сложнее из-за появления неявных путей выполнения.

Я может чего-то не понимаю, но если ошибки обрабатываются, то пути исполнения в итоге будут одинаковыми. Что с исключениями, что с кодами возврата/std::expected. А в таком случае и ошибки в логике будут одинаковыми.

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

Но с тем, что корректная работа с исключениями может требовать большей подготовки я скорее согласен. Та же exception safety - это та ещё головная боль, регулярно требующая особого подхода.
Но с бест практисами код получается надёжнее, чем код без исключений.

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

Почему?

Потому что такой код с -fno-exceptions будет не корректным. Он будет работать не так, как код с -fexceptions. Если падать в случае чего - это допустимое поведение, то хорошо, но сравнивать корректную обработку исключений и std::terminate на любой чих не показательно. Т.е. тут понятно, почему -fno-exceptions работает быстрее, но такой вариант применим не так уж часто.

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

Ещё чуть чуть.

Интроспекция, рефлексия, объекты которые обладают семантикой, ... реально разработаны и используются!

А в тредах об RAII «щёки надувают».

Может быть поэтому мои посты «какие-то не такие».
Поэтому-то посты похожи на «Ivan_qrt, Forum0888 и щука».

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

Интроспекция, рефлексия

Нет в стандарте плюсов. Когда compile time рефлексию завезут в стандарт, будем и за неё щёки дуть. Пока рано.

объекты которые обладают семантикой

Х.з. что это, но звучит как источник граблей.

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

Рад за Вас!
У меня уже ныне интроспекция - «обыденность».

Шутка

Улыбнуло однако - ЖДУНЫ!

Их на форуме - МОРЕ!
И любят ПОКАЗАТЬ свои «ЗНАНИЯ»!

Поскромнише ЖДУНЫ нужно быть, поскромнише (пост не о том, что я лучше. Просто разработчикам не полезно «щёки надувать»).

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

Интроспекция, рефлексия,

«Достаточно сказать, что я ускорил server-side в 40 раз, просто выкинув его систему кеширования. Какая_ирония.jpeg» В которой как раз была рефлексия. Короче, расстрелять. Точнее, в игнор. Один хрен это какой-то старый тролль перерегистрировался и за истерически-восторженным (и, увы, достаточно безмозглым – впрочем, что от тролля ожидать) флудом пытается спрятаться от собственного одиночества. Ощущение знакомое, но сочувствовать не буду.

Когда compile time рефлексию завезут в стандарт,

👍

будем и за неё щёки дуть.

А вот щёки дуть там будет особо не из-за чего. (1) Кому надо, у тех давно всё это есть, clang libtooling называется. (2) С помощью которого можно трасформировать код ваще произвольным образом, в отличие от.

И вообще, идея метапрограммы (трансформирующей сорцы) как части трансформируемой программы – несколько идиотична в своей концептуальной ограниченности.

объекты которые обладают семантикой

Х.з. что это, но звучит как источник граблей.

Возможно, имелось в виду зашивание правил бизнес-логики в систему типов. Тогда это не источник граблей, а строго наоборот.

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

Даже не сомневаюсь. До некоторого порога сложности исключения не нужны вовсе. Тут можно привести аналогию с автомобилем, например - если накрылся генератор, например, человек же не выкидывает все авто, он меняет одну лишь деталь и пользуется дальшше. Также и с программой - когда она усложнилось достаточно, отчетливо очерчены раздельные модули (и они спроектированы с умом), то при поломке одного из них мы можем не падать целиком, перезагрузить/сменить на другой/отцепить один лишь этот модуль, сказать чего-нибудь в лог и работать дальше. Без исключений это все превращается в боль с протсаскиванием по стеку 100500 флагов состояния.

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

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

Спасибо (https://clang.llvm.org/docs/LibTooling.html)!

У меня интроспекция поддержана не в compile time, а run-time.
Профита много больше.

Весь API для run-time.

Привязки к компиляторам никакой.
Можно использовать в исходниках любого ЯП.

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

https://clang.llvm.org/docs/LibTooling.html интересен (покопаю).

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

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

т.е. добавить «нечто», потом «отрубить все у этого нечто» и шо? зачем все это?!

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

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

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

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

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

а очень хорошую жопу можно и наждачкой подшкурить!

sunjob ★★★★
()

ПФФФ… На «проклятых» винде и макоси давно на плюсах драйвера пишут и не парятся. И тыкают пальцем в дремучих линуксойдов. А где то и палочкой тыкают. ))

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

ПФФФ… На «проклятых» винде и макоси давно на плюсах драйвера пишут и не парятся. И тыкают пальцем в дремучих линуксойдов. А где то и палочкой тыкают. ))

Драйвер - понятие растяжимое.

Если это транслятор вызовов шины в вызовы системы, коим является наверное 80% драйверов - хоть на баше их пиши.

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