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)

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

А C++ ЗАГНЁТСЯ!

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

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

Здесь Вы правы!
Разработаю (но скорее всего велосипед изобретать не буду).

Иван, посты мои о разработке и зря Вы их в «штыки» берёте.

Вот смотрите, некий программист разработал возможность использования метаданных в run-time.
Что в этом плохого?
Вместо того, чтобы вести обсуждение, его дурачком называют.

Это ИМХО обычное ХАМСТВО.
Так нельзя вести диалоги.

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

Единственная нужная гарантия после исключения - максимально корректо деструктнуться модулю, без сегфолтов. А от кодов возврата можно требовать консистентности состояния, если не удалось, то повод кинуть исключение.

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

Что в этом плохого?

в run-time

this. Тут тема о плюсах. Метаданные в рантайме в плюсах кто только не изобретал. Но они тут не нужны, т.к. это накладные расходы. Сделай метаданные в compile time, и сообщество это как минимум рассмотрит, а возможно и спасибо скажет. Метаданные в рантайме не пользуются популярностью.

Вместо того, чтобы вести обсуждение, его дурачком называют.

Ну лично я тебя дурачком не называл (хотя местами можно), а только указывал на бессмысленность твоих постов. И я действительно не понимаю их смысла. Как из-за стиля изложения, так и из-за содержимого. Будет адекватная тема - можно что-то обсудить, а по 1С и подобному мне просто нечего сказать.

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

Будет адекватная тема - можно что-то обсудить, а по 1С и подобному мне просто нечего сказать.

Всё понятно с вами.
Просьба мои посты не комментировать.

Без обид, из ваших постов очевидно, что вы «не в теме», но «мнение имеете».

Скромнише нужно быть, скромнише.

ЧСВ вреден для разработчиков и весьма!

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

Иными словами ты считаешь, что исключения в плюсах должны использоваться только как паники в go или расте. Комитет стандартизации и большая часть разработчиков с тобой не согласны. Зачем ты сюда вообще приплёл exception safety тоже не ясно.

А от кодов возврата можно требовать консистентности состояния

Т.е. гарантии безопасности на кодах возврата - это ок, а с исключениями - адский ад? Сомнительная история.

Ты себе придумал какую-то мантру и пытаешься за неё агитировать, забыв объяснить чем оно лучше стандартного использования исключений и зачем вообще таким разделением заморачиваться.

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

Просьба мои посты не комментировать.

Отказано (я не имею желания запоминать хотелки анонимов на лоре).

что вы «не в теме», но «мнение имеете».

Это да.

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

И я действительно не понимаю их смысла. Как из-за стиля изложения, так и из-за содержимого.

Ты не один такой)

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

Скромнише нужно быть, скромнише. ЧСВ вреден для разработчиков и весьма!

Лол, ты сам последуй своему совету для начала.

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

Отказано (я не имею желания запоминать хотелки анонимов на лоре).

Да, аноним.

Это да.

А вот за это РЕСПЕКТ!

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

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

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

Чуть менее чем ВСЕ твои комменты это какая-то херня не по делу: то «а я вот пишу идеальный код, но вам его не покажу, просто похлопайте какой я классный», то «бог есть, я вам повторяю, бог есть!», то «ой это всё высокоумие», то ещё какой-нибудь ЧСВшный тупизм.

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

Upd: а да, ещё забыл искромётный юмор, предваряемый словом «шутка».

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

То что вы частенько поучаете всех

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

и ярлыки вешаете, это как?

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

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

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

Понятно.
Великий УЧИТЕЛЬ!

Скажу вам по секрету.
ЛОР, это пристанище ИЗБРАННЫХ.

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

Вот, поэтому лучше нам не быть «УЧИТЕЛЯМИ» и вести дружеский диалог.
Профита больше будет.
А кидаться постоянно какашками это - ЧСВ.

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

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

Ты придумываешь за меня. Если отмотаешь назад, то увидишь «растаманы не осилили исключения», что как бы намекает, что это вещи разные. Раст после паник не встает, после исключения можно (после радикальных мер).

Зачем ты сюда вообще приплёл exception safety тоже не ясно.

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

Т.е. гарантии безопасности на кодах возврата - это ок, а с исключениями - адский ад? Сомнительная история.

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

Ты себе придумал какую-то мантру и пытаешься за неё агитировать, забыв объяснить чем оно лучше стандартного использования исключений и зачем вообще таким разделением заморачиваться.

Почему ты считаешь свой взгляд стандартным? Библиотека СТД вполне подтверждает мои взгляды, я знаю только одну функцию уродца, которая шлёт исключение не по делу stoi. Твой подход ущербен и создает лишь одни проблемы на практике. Думаю, что ты либо исключениями не пользуешься, либо на плюсах вовсе не пишешь, мне страшно представить, как я сейчас бы на своем проекте заморочился бы со strong_exception_safety.

Ты не дозрел до понимания того, что исключения лишь для критических ошибок.

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

Категоризация - единственный доступный людям способ осмысления, т.к. ресурсы мозга конечны.

Это не просто нормально, так делают буквально все и со всеми. А вот самообман - это так себе занятие.

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

«а я вот пишу идеальный код, но вам его не покажу, просто похлопайте какой я классный»

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

Соглашусь лишь с тем, что на ЛОР эта тема никому не интересна.
Это очевидно и пожалуй профита от этих постов НИКАКОГО.

В приоритете обсуждение стандартов C++ и всё вокруг них.

Что касаемо исходников, то в ЛОР все дураки: Линус, Вирт, ...
Это не правило, а АКСИОМА!

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

А вот самообман - это так себе занятие.

Здесь с вами согласен, но ведь разрабатываемое API весьма эффективно.
Так что самообмана, нет.
Самообман это, когда реальной разработки нет и лишь фантазии «диванного теоретика».
Ничего не знаю о ваших разработках и не сужу о них ...

Шутка

ВЕЛИКИЙ УЧИТЕЛЬ, то и дело «избранного» уму разуму учит.
Никак не уймётся.

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

Раст после паник не встает, после исключения можно (после радикальных мер).

И в расте, и в go паники можно перехватывать. Технически паники ничем от исключений не отличаются, как правило. Только идеологически.

необходимо соблюдать strong_exception_safety

Только для тех операций, после которых тебе понадобится использовать данные в случае ошибки.

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

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

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

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

Библиотека СТД вполне подтверждает мои взгляды

О подавляющем большинстве ошибок STL сигнализирует исключениями. Из этого есть исключения, типа стримов с их флагами, но в основном ошибки из STL - это исключения.

Для примера можно взять банальный at() в векторе. Он бросает, а не возвращает код. Можно ли считать это фатальной не восстановимой ошибкой?
А если это считать априори критической ошибкой, то что тогда не критическая?

Твой подход ущербен и создает лишь одни проблемы на практике.

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

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

ВЕЛИКИЙ УЧИТЕЛЬ, то и дело «избранного» уму разуму учит. Никак не уймётся.

Думаешь зря? Ученик безнадёжно необучаем, да?

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

Думаешь зря? Ученик безнадёжно необучаем, да?

Вообщем то по хорошему нужно благодарить его за посты.
Проблема в том, что многие часто переходят на личности и в добавок «пофилософствовать» о ЧСВ.

А всё ведь просто.
Адекватный не будет в диалогах переходить на личности.

Проблема здесь вовсе не в «обучаемости» и люди часто через какое-то время меняют свой характер к лучшему.
Как-то так.

Что касаемо постов о C++, то посты скорее о разработке.
В целом C+++ РЕСПЕКТ!

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

Для примера можно взять банальный at() в векторе

Ну критическая ошибка, самая настоящая. Сегфолт по сути, в логике явная проблема.

А если это считать априори критической ошибкой, то что тогда не критическая?

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

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

Ок, давай финалить, иначе всё по кругу будет.

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

Sorry, но на это суждение обязан ответить.

Так да. В великой нужде появляются Великие Учителя.

ПО ВЕЛИКОЙ НУЖДЕ!

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

Весь остальной сок твоего мозга опускаю

а и зря, там как раз о самом главном:

уровень подготовки, совести и ответcвенности...

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

Это да, а ещё лупше, чтобы C+ использовали, а там уж и Си совсем близко («Образованные просто одолели»).

Вообщем, против использования C++ в ядре (и дело вовсе не в C++).

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

чтобы он возвращал std::optional вместо киданий исключения

Тот же find в контейнерах может его возвращать.

LongLiveUbuntu ★★★★★
()

C++ умирающий язык, какой смысл тащить его в ядро? Ещё Кобол затащили-бы.

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

Rust пихают.

Лучше бы пихали ADA. Потому что мой любимый язык,да :-)

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

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

текст на плюсах куда более читаем, чем на сишке

А вы разбираетесь в сортах. Как по мне - сишка/кресты уродливее даже перла и пыха

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

Да затем, что если ты пытаешься использовать данные в модуле после возникновения в нем исключения, то тебе необходимо соблюдать strong_exception_safety

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

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

Для этого вам basic safety и придумали.

Такая ветвь выполнения, где все накрылось п*****, не надо там никаких особых гарантий.

Аналогично. Стронг - не надо, вот вам basic и придумали.

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

Тут вообще не понял. Гарантии обеспечивает кидающая, а не проверяющая сторона.

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

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

Ты не дозрел до понимания того, что исключения лишь для критических ошибок.

Хотите так делать - ограничьтесь бейсик сейфти. Хотите НЕ так делать - ну тогда есть стронг сейфти. Проблема-то в чём?

Кстати сказать, открою вам вселенскую тайну. Ядро линукса, в плане кодов возврата, уже отходит от стронг гарантий. Сейчас, если сисколл вернул ошибку, то состояние могло измениться. Это связано с тем, что очень много функций имели в конце огромные простыни кода, обеспечивающие откат к изначальному состоянию, если что-то пошло не так. Эти простыни кода были крайне сложны и ни кем не протестированы. Теперь от такой практики отказываются, дабы избежать уязвимостей. В результате, если какой-то mmap() мапировал поверх пользовательской области, частично её перезаписал, а потом столкнулся с ошибкой, то он только отмаппирует уже «сделанный» кусок, но прежний маппинг в нём восстанавливать не станет. Так как это крайне сложно. В результате, в общем то, на стронг гарантии забили ВСЕ, а не только пользователи исключений. Так о чём тогда вы спорите? :)

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

Даже если предупреждаешь, всё равно потом лет пять «вспоминают».
Ты ж говорил, ...

Sorry, настроение хорошее.

Обязательно в этому году начну разработку API для использования баз знаний.
Неплохое core для этого уже есть!

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

По мне так добавить в Си несколько фичей, которые позволят кодить более сейфово, и можно оставить всё как есть, поменять только code style.

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

Легче понимаемый код? Это вы type deduction не делали в шаблонном методе шаблонного класса, обёрнутого в шаблонную лямбду.

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

По мне так добавить в Си несколько фичей, которые позволят кодить более сейфово

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

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

Много раз говорил и ещё раз скажу.

Си был спроектирован именно для разработки алгоритмов и без всяких «бантиков» (хотя и их в язык напихали не мало).
Остальное всё можно достигнуть через разработку API.
Ныне в тренде «косы заплетать».

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

Си был спроектирован именно для разработки алгоритмов и без всяких «бантиков»

Он был спроектирован для написания портабельной OS, в первую очередь. Многие решения там спорные и ситуативные. И это было давно и реалии серьезно поменялись. В общем, Си тоже устарел, но в настоящий момент в этой нише заменить его нечем.

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

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

«для разработки алгоритмов» в те додревние времена были фортраны с коболами. C проектировали для того, чтобы программист мог заниматься низкоуровневым байтодрочерством хоть сколь-нибудь независимо от аппаратной архитектуры, не сильно вывихивая себе мозги фортами и макроассемблерами.

arkhnchul ★★★
()
Последнее исправление: arkhnchul (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.