Модули ядра на С++

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

хмхм... в принципе ясно... тогда просто академический интерес ;)

Of course. As an example, see http://pdos.csail.mit.edu/click/

Thanks.

А для чего оно может понадобиться?

Murr:
> А для чего оно может понадобиться?

ну, и где пропадал?

только не говори, что работал... а то мне завидно
станет.

idle:

Месяц с лишним - отпуск, 
неделю заживала нога после того, как свора собак покусала,
месяц - фарингит,
остальное время работал;

P.S. sorry за offtopic.

Это тупость.

Speed of development.

>Speed of development.

Модули ядра предполагаются маленькими и примитивными, где интерфейсы определяются ядром, а код минимален. Какого рода модуль ты бы стал разрабатывать на C++? Либо он выйдет гораздо большем, чем на "чистом C", либо ты тянешь в ядро то, что там быть не должно.

Use CORBA & perl - http://www.nondot.org/~sabre/Projects/#korbit

:)

> Существует ли какая-то возможность писать модули ядра на С++ ?

Да.

Но при этом придётся самостоятельно реализовывать поддержку C++'ого runtime'а в ядре. new/delete, RTTI, создание/разрушение статических объектов, исключения, STL и т.п.

> Какого рода модуль ты бы стал разрабатывать на C++?

Нечто, обладающее двумя признаками:
1). реализовать это "нечто" на C будет намного сложнее, чем на C++
2). жёсткие требования к производительности

> Либо он выйдет гораздо большем, чем на "чистом C",

Нет.

> либо ты тянешь в ядро то, что там быть не должно.

Смотри п.2.

execve:

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

Murr:

> не вижу четкого примера. Какой-то странный набор характеристик и все.

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

> Кстати, с каких пор C++ код стал более производительным по сравнению с C? Или я неправильно понял пункт 2?

С каких пор C++ код стал _менее_ производительным по сравнению с C? Хотя начинать очередной виток флейма на эту тему мне очень не хочется...

I am sorry for writing in English, but I do not have a Cyrillic keyboard accessible.

Besides Click, I was involved in two cases in which development was deliberately undertaken in C++ - and not in C - in sake of shorter time to market.

In both cases the module was a driver for a kind of NIC. In both cases the module was part of a turn-key solution. Using stricter compiling rules, richer language semantics and other traits of C++ (pun intended), we were able to get the product running in half of time we anticipated the development will take in C.

In one case the driver had to be developed both for Windows and for Linux. By using C++ we had abstracted some routines and were able to share large portions of code.

Most of the time we had cut was in - testing (by having the compiler catch more bugs for us during compilation time our testing cycles were shorter) and code reuse (same).

Of course, similar result could be accomplished in C - even while using the original design. This is true, of corse, for the code reuse (in cross/developed module) as well. The development time, however, would be higher - thus raising cost of development and possibly jeopardizing the deal.

Thanks.

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

Использовать C++ для того, чтобы создавать драйвер, собирающийся и в Windows и в Linux тоже сложно, т.к. интерфейсы драйверов Windows и Linux достаточно сильно отличаются, поэтому отличается и структура драйверов. Возьмите и посмотрите драйвер ext2 в Linux и ext2fsd в Windows NT, написанный на основе первого. Утверждение того, что можно инкапсулировать чуть по-разному называющиеся функции выделения памяти, использования семафоров и др. и сохранить структуру драйверов между Linux и Windows, говорит о глубоком непонимании архитектуры драйверов в Windows и Linux.

>The development time, however, would be higher
Development time зависит от объема кода и прямолинейности оного.

не выдержал и встряну, вотки выпив :)

я, в принципе, согласен почти со всеми аргументами
ПРОТИВ C++ в кернел. я только не понимаю, зачем
усложнять жизнь тем, кто этого все-таки хочет.

include/linux/device.h:
        struct class {

ну на фига? легко обходится, конечно, но все же.

лично я писал (просто так, для интереса) модули на
C++, и вполне понимаю тех, кто это делать хочет.

> Драйвер (будь то железки или файловой системы или еще чего)
> - очень простая вещь

вот с этим не согласен :) совсем не обязательно простая.
но дело, конечно, не в этом.

>вот с этим не согласен :) совсем не обязательно простая.

Простая не в смысле семантики кода, а в смысле объема и структуры кода, необходимого для реализации нужных функций. В большинстве случаев структура (скелет) определяется подсистемой, к которой можно условно отнести драйвер, остальное распадается на реализацию отдельных функций, которые должны работать правильно и быстро, но не представляют задачу "проектирования".

Может быть существуют настолько сложные и недружественные железки(или сложные и очень критичные ко времени обработки), что нельзя вынести логику за вычетом I/O в userspace, но я пока с такими не сталкивался, поэтому и попросил у товарища разумный пример. Примером того, что вполне можно обойтись без C++, является сам Linux.

You almost never HAVE to use C++. Another example of "getting away without using c++" can be mldonkey, written in ml, original bittorrent, written in python and original FIX protocol stack, written in Cobol.

Everything may be written in everything. With enough skill, runtime characteristics may be satisfactory.

If you'd like examples of relatively complex kernel-level applications, you may consider any wire-speed network processing appliance, where getting each packet into user-space is unacceptable (performance wise), yet amount of processing per packet may vary greatly (almost nothing for a switch, a lot for modern intrusion-prevention system, with various load-balancers, bandwitdth management appliances and forensics tools somwhere in-between). This is surely not a "driver" per-se, but one big complex system.

я приведу только один пример.

когда-то struct timer_list не имел ->lock поля. затем оно
было добавлено. пришлось вводить init_timer(), и перелопачивать
весь код, использующий таймеры, и добавлять TIMER_MAGIC,
и проверять его при всех операциях с timer_list, и ловить
bug-report'ы довольно долгое время.

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

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

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

кстати как ни странно, на Pascal модули писать можно.. будут геморои сделать .mo, но это можно победить.. а вот куды деть new в ++ ? как должен выглядеть vtables ядра ? как пихать template ?? абзец..С++ хороший язык, но не лучший и уж точно не для ядра.. если писать ядро с нуля, то Ada или Modula3, а еще лучше C ;-)

> а вот куды деть new в ++ ?

это самое простое.

> как должен выглядеть vtables ядра ?

и это решается. хотя... не очень понятно что имеется в
виду.

наконец, вы можете просто не использовать new и virtual.

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

> если писать ядро с нуля, то Ada или Modula3

это просто флэйм.

> Может быть существуют настолько сложные и недружественные железки(или сложные и очень критичные ко времени обработки), что нельзя вынести логику за вычетом I/O в userspace, но я пока с такими не сталкивался, поэтому и попросил у товарища разумный пример. Примером того, что вполне можно обойтись без C++, является сам Linux.

Товарищ говорил про модули ядра, а не device drivers. Разницу видишь? ;)

Что же касается простоты - смотри пункт 2. Я тоже за то, чтобы в общем случае тащить в ядро только минимум кода, а всю сложную логику писать в user-level'е. К сожалению, такое решение не всегда устраивает по производительности.

Просяснб ситуацию, сорри что сразу не сделал. Есть куча кода, образно МАС-бридж, своеобразный буфер между Ethernet и TCP-стэком. Это куча кода работает на куске текстолита, на плате то есть. Дело в том, что сейчас это работает на vxWorks, то есть в реал-тайме, но по некоторым причинам захотелось перейти на линух, такой же реал-тайм. :) Сейчас весь бридж написан на С++. Десяток классов, которые обеспечивают работу с портами на плате и собсно маршрутизацию пакетов на МАС-уровне, сверху на это безобразие навешиваются всевозможные протоколы, как то IGMP (igmpsnoop-ing), SNMP, NTP, VLAN, PPPoE, VoIP и куча других...

При переходе на линух хотелось бы ядро этого бриджа запихнуть в kernel-space, ядро бриджа взаимодействует с device drivers для Ethernet и DSL.

Вот потому, что бы не переписывать более сотни файлов на С, и хотелось бы портировать то, что есть на линух. Потому и вопрос такой возник.

Конечно же, будут писаться и device drivers, но их проще переписать на С, но ядро бриджа слишком объемное, а сроки поджимают...

У нас ситуация была немного другая: код для ядерного модуля писался с нуля сразу же на C++.

Про все проблемы с C++ в ядре мы знали, но достоинства (скорость разработки, в первую очередь) перевесили недостатки.