C++ в ядре Linux

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

> Несколько конечных автоматов :) Встречный вопрос: что дает
> многопоточность для одного процессора?

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

> А Вы задумывались вообще зачем на одном процессоре нужна многозадачная ОС?

Именно потому, что никто (пока) не умеет строить таких конечных автоматов. Кокс абсолютно прав.

> Ну объясни, пожалуйста.
Ну очень просто - даешь команду видеокарте отрисовать прямоугольник и залить, дальше работает карта, на то у нее и процессор с вентилятором :)

Тоже самое IDE и SCSI, дал команду - записать блок данных, а они сами разбираются.

Разумеется, все вышесказанное делается не напрямую, а через API OS.
Но параллелизм на одном процессоре получается в таких ситуациях.

> Почему "значит"?
Ну потому, что операция асинхронная.
Пример - программа ждет ввода из COM-порта, и выводит его на экран. Дак вот это могут быть два потока. Один ждет, второй рисует UI. Причем пока первый ждет, то на втором можно бегать по менюшкам, менять настройки и способ отображения и т.п.

> Если есть "другой поток", значит эта программа - гибрид ужа с ежам.
Не понял Вас, честное слово.

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

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

С такой формулировкой соглашусь.
Вострога и у меня сейчас от С++ нет. Но что в этом мире совершенно?

>>Мдэ, нет чтоб в сторону асма двигаться, визуал васика скоро всунут
>>8)

Угу. Переписать ядро линуха на асме... Целиком... Думаешь что говоришь? И что, прощай потом мультиплатформенность?

Как хорошо, что Apache на C!

Оно _уже_ на асме. Портабельном. Частично.

Эхма, лучше даже не спорь про многопотоковость :) Недавно наблюдал изнутри IBM про судорожное внедрение асинхронности везде где не попадя в z/OS ;)

>> Оно _уже_ на асме. Портабельном. Частично.

Ой не смеши людей. Примеры - в студию. В смысле примеры "портабельного ассемблера". К примеру скажем x86 и IBM zServer

> В смысле примеры "портабельного ассемблера".

Так часто называют язык программирования Си.

Ну это скажем так иносказательное именование.

Речь про настоящий ассемблер ;) И где его там так много в ядре линуха? ТАм хорошо его если 1%. А то и его нет :)

> Ну почему все С++ считают сложным? Это похоже на фобию повсеместно
> распространненую в России. Да прочитайте хорошую книгу по нему,
> выучите наконец язык.
А вы-таки с этим не согласны? Может проведем сравнительный анализ сложности С++/Java, C++/Object Pascal, C++/C#, C++/PHP5 или вообще C++/Perl, C++/Lisp...?

C++ - это как минимум возможность в сотый раз не изобретать аналоги std::vector/list/set/map/hash_set/hash_map и множества алгоритмов, а использовать готовые шаблоны.

Причём шаблоны обеспечивают жёсткую проверку типов, чего в C ни через макросы, ни через void* не получится. И возможность сгенерировать из шаблона инлайн (нука покажите мне, как стандартный сишный qsort инлайнится? std::sort такое умеет).

Какое замечательное буйство студентов по поводу супер крутого программирования на С++. Ув. знатоки, будьте добры - приведите пример задачи для которой необходимо применение ООМ. Такой задачи которая бы подругому не решалась бы.

И еще: сформулируйте ктонибудь пожалуйста - почему в ядре нельзя использовать С++.

Выбор языка программирования в задаче которая делается "для себя" зависит от способа мышления программиста. Если программа ему представляется как оператор следующий за оператором, образующий функцию и т.д. то врядли он выберет С++.

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

Согласен, пока чувак вкурит C++ у него всякий аппетит пройдет что-то контрибутить в Линукс. И разработка заглохнет.

Интересно, на чём написаны драйвера у nVidia...
Не удивлюсь, если на C++.

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

Всё можно решить по разному. Так что вопрос в удобстве. Например, если надо сделать код, который будет подстраиваться под конкректные ситуации, скажем на одном компе оптимально один подход использовать, а на другом - другой, то удобнее использовать полиформизм, чем присваивать адреса функциям. Хотя, конечно, всё зависит от количества. 3 функции будут проще ручками присвоить...

4anonymous (*) (29.10.2004 12:14:14):
>Ну очень просто - даешь команду видеокарте отрисовать прямоугольник и
>залить, дальше работает карта, на то у нее и процессор с вентилятором :)
>Тоже самое IDE и SCSI, дал команду - записать блок данных, а они сами
>разбираются.

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

Теперь о Коксе, FSM и тредах:
Давайте будем рассматривать разности в реализации чего-то конкретного, не мешая всё в кучу (видокарты, IDE и прочая).

Самое избитое, хотя бы, возьмём - один сервер, много клиентов (httpd?). Как показывает практика, на одном процессоре FSM реализации эффективнее тредовых. А асинхронные операции эффективнее FSM. Преимущества тредов в том, что уровень абстракции, предоставляемый ими, более понятен и близок человеку. Одна задача - один тред. Один клиент - один тред, и т.д. Минусы же огребаются в синхронизации.

//Loseki

> А вы-таки с этим не согласны? Может проведем сравнительный анализ
> сложности С++/Java, C++/Object Pascal, C++/C#, C++/PHP5 или вообще
> C++/Perl, C++/Lisp...?

Нет уважаемый eXOR, я с Вами не согласен. Все перечисленное Вами одинаково просто.

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

Что выбрать в конкретном случае? Ответ прост:
1. Для какого языка есть наиболее развитый инструментарий для решения вашей задачи (средства отладки, библиотеки и т.п.)?
2. Что знает Ваша команда?
3. Достаточно ли она smart что бы выучить новый язык? И есть ли на это время и средства?

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

Еще один фактор - интеграция. Глупо писать на C++, что бы потом интегрировать это в систему на Java. Есть конечно JNI, но надо хорошо подумать.

> Не всё так просто. Как там.. "сейчас, сынок, дискетку доформатирую".
> От этого треды не спасут. Просто вынос каких-то операций в треды ещё
> не означает, что они никак не будут влиять на всё остальное.
Что-то я не понял ход Вашей мысли. Я лишь указал на те ситуации, когда CPU свободен и хоть он и в системе один, но может в такие моменты поработать над другими задачами.

> Теперь о Коксе, FSM и тредах.
Давайте обсудим.

> Самое избитое, хотя бы, возьмём - один сервер, много клиентов (httpd?).
> Как показывает практика, на одном процессоре FSM реализации
> эффективнее тредовых. А асинхронные операции эффективнее FSM.

Не могу аргументированно возразить, т.к. не имел возможности сделать сразу три реализации их сравнить. Но есть некоторые свои соображения:
1. Переключение контекста потоков более легкая операция, чем переключение между процессами. И тут мне кажется лучше не форкаться без особых причин.
2. Асинхронный вывод действительно эффективнее, чем несколько потоков пишущих параллельно (оставлю без объяснений).
3. Асинхронный вывод не всегда решает проблему параллельности. Например, параллельное вычисление и отрисовка. Отрисовку ни как не сделаешь асинхронный.

И Вы сделали правильное замечание - "на одном процессоре". Выбирая архитектуру будущего ПО, нужно учитывать на кого оно ориентировано. Если на home users, то тут явно будет один процессор. Если на корпоративных пользователей, то процессоров будет больше.

> Одна задача - один тред. Один клиент - один тред, и т.д.
Абсолютно не верно! У такой системы совершенно не предсказуемое поведение, при увеличении нагрузки явно она упадет!
Лучше так:
Один поток - слушает сокет. Пул потоков фиксированного размера обслуживает клиентов. Клиенты стоят в очереди, если нет свободных потоков. Может быть отдельный поток для ведения логов.

>Не могу аргументированно возразить, т.к. не имел возможности сделать сразу три реализации их сравнить. Но есть некоторые свои соображения:

"Всё уже украдено до нас" ;) Поищите работу, из которой вырос веб-сервер Zeus и листовку с описанием C10K problem.

>1. Переключение контекста потоков более легкая операция, чем переключение между процессами. И тут мне кажется лучше не форкаться без особых причин.

(Держа в уме, что основная мысль - это FSM против тредов): Как связаны FSM и "переключение контекста потоков?"?

>3. Асинхронный вывод не всегда решает проблему параллельности. Например, параллельное вычисление и отрисовка. Отрисовку ни как не сделаешь асинхронный.

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

>Абсолютно не верно! У такой системы совершенно не предсказуемое поведение, при увеличении нагрузки явно она упадет!

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

//Loseki

From: Linus Torvalds [email blocked] Subject: Re: Compiling C++ kernel module + Makefile Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST)

On Tue, 20 Jan 2004, Robin Rosenberg wrote: > > This is the "We've always used COBOL^H^H^H^H" argument.

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

- the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either (a) looking for problems (b) a C++ bigot that can't see what he is writing is really just C anyway (c) was given an assignment in CS class to do so.

Feel free to make up (d).

Linus

Чуваки не ведают что творят. Если в ядро придет C++ это будет конец Линкусу (ИМХО). Просто, ИМХО, ядро пишется по принципу написали, посмотрели, подумали, поправили...

Плюсовые программы так писать нельзя, нужно сначала думать, правильно сочинять объекты, проектировать классы. По ходу написания программы что-то переигрывать бывает сложно. Совсем говеную программу на C++ гораздо сложнее понять и поравить чем просто C.

Концепция Линукса --- напишите примитивную программу, а потом усложняйте, концепция С++, ИМХО, --- поймите все что нужно от программы, спроектируйте, напишите.

... и бога ради ничего не трогайте если оно как-то работает?

>... и бога ради ничего не трогайте если оно как-то работает?

именно, вот так и будет с С++, "Эффект бабочки".

лемму о бабочке знаю
эффект бабочки -- нет

нихрена он не понимает в современных методах разработки.

если чел не в состоянии осилить плюсы это не дает ему права всех остальных идиотами обзывать

> лемму о бабочке знаю. эффект бабочки -- нет

Читай Рея Бредбери.

Мужик полетел в прошлое и наступил там на бабочку.
Вернулся в настоящее - а тут президент другой.

> - the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.

Никто насильно не заставляет юзать C++ exception handling. Можно писать на С++ и без него.

> - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

Язык С тоже скрывает некоторые детали по части распределения памяти под переменные, в отличие от ассемблера, где все это делается вручную. Что из этого следует: что С isn't a good choice for a kernel.

> - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

Ага, ассемблер тоже позволяет писать объектно-ориентированный код _без_ завязки на глюки компилятора С.

IMHO, это письмо Линуса больше говорит о его консерватизме, нежели о каких-то преимуществах С перед С++. Наверняка подобное неприятие нового имело место и при переходе с ассемблера на С (30 с копейками лет назад): ну типа как же так, ядро на языке высокого уровня, да вы с ума сошли.

Естественно, С++ по сравнению с С имеет не только плюсы, но и минусы (как и все остальное в нашем несовершенном мире). Главный минус применения С++, IMHO -- человеческий фактор. Этот язык сложен и полон неожиданных засад для тех, кто его не знает, но знает С.

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

Простой вопрос. Послезавтра команда gcc опять сменит мэнглинг для ++. Ваше ядро написано именно на плюсах. Ваши действия?

Ну сменит мэнглинг, ну и что? Поменяется ABI? Так ABI для ядра все равно нет, так что меняться нечему. (Имеется в виду "нет стабильного бинарного интерфейса, независимого от версии, патчей и сборки". И не будет -- так сказал Линус.)

Кстати, ты, наверно, думаешь, что при использовании С нет проблем вокруг компилятора? Они есть -- вспомни эпопею со сборкой ядра gcc-2.96. Посмотри в /usr/src/linux/Documentation/Changes: там явно прописано, какими версиями компилятора следует собирать ядро. Собирать другой версией -- значит напрашиваться на грабли. По твоей логике получается так: нах эти завязки на компилятор С, лучше на асме писать, потому что код при этом не зависит от версии транслятора. Да?

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

че за херня? рейкъявик в швеции всю жизнь был

Анонимусам надо учить географию. Рейкьявик это Исландия. Гугль в помощь.

>нихрена.. тока питон!

Есть задача a

Есть время b

Есть есть c человек в в каждой гуппе

так вот- если время не стремится к бесконечности то

качество (a, b, c, c++) > качество (a, b ,c, plain c) для охуенного круга задач. равно и скорость (в сулу меншего количества воркэрандов) вызванных запаркой

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

>MHO, это письмо Линуса больше говорит о его консерватизме, нежели о каких-то преимуществах С перед С++. Наверняка подобное неприятие нового имело место и при переходе с ассемблера на С (30 с копейками лет назад): ну типа как же так, ядро на языке высокого уровня, да вы с ума сошли.

Вообще же я читал что "Я бы и написал на плюса= был бы компайлер". Щаас он есть, равно как и херова гора гемороя, называемая Linux kernel. Кто против - вперед -

find /usr/srclLinux/ -exec cat | grep hack | wc -l find /usr/srclLinux/ -exec cat | grep fuck | wc -l find /usr/srclLinux/ -exec cat | grep 'complete hack' | wc -l

Это так, для анализа качества кода иподходов к работе.

В 2.6.8 слово "fuck" встречается ровно 2 раза, и оба раза в фразе "/* Ugly, ugly fucker. */"

По-моему, всё гораздо проще. C++ - нормальный язык, но написание на нём ядра имеет смысл только для полностью ОО систем (да-да, чтобы и API был через класса). Пока таковых на горизонте по-моему не наблюдается. А вот встраивание C++ кусков в большую систему, написанную на чистом Си - действительно громоздко и чревато.