Здравствуйте!Пишу драйвер для ucLinux и хочу реализовать драйвер на С++, а не на С.
Возникла проблема линковки - линковщик не понимает объектные файлы созданные g++.
В частности имены функций в объектных файлах скомпилированных gcc и g++ создаються по-разному.
gcc: _funcname
g++: __Z7funcnamevЕсли в .cpp файле функцию заключить в extern "C" { void funcname() {} }, то имена ф-ии в объектниках g++ делает как и gcc, однако по прежнему
: undefined reference to `funcname'.Вопросы:
1) как сделать чтобы код С++ нормально собирался с ядром линукса?
2) какие подводные камни возможны при использовании С++ в ядре линкса?
Для gcc для зборки с++ надо подключать -lstdc++ .
>Для gcc для зборки с++ надо подключать -lstdc++ .А вот и не надо. Так же как нельзя подключать libc для сишного кода в ядре. Вот только какой C++ получится без libstdc++... Сомневаюсь, что выйдет что-то разумное.
Пока решил не пользовать С++ в ядре, однако разобраться все же интересно.http://pograph.wordpress.com/2009/04/05/porting-cpp-code-to-.../
Вкраце:
<< Мы все знаем что использовать С++ для написания модулей ядра - плохая идея...
но если всеже надо, то:1) Most features of C++ will work, virtual functions, templates, operators, etc. But their is no default implementation of new and delete operators, so you need to write your own.
2) Stack space is very limited. In Linux kernel, default size of stack is 2 pages... Due to this constrain, you can’t use exceptions in kernel, because exception needs too much space in stack. >>----
Почему хочу писать на С++:
1) с помощью классов и функций-членов легче структурировать и логически разделить на часть программу.
2) нужны stl-контейнеры (вектор, очередь).
использование остальных свойств языка (шаблоны, исключения, и т.д) пока не предвидиться.Хочеться оргументированный ответ чем плох С++ для ядра линукса.
Философский вопрос про яйца :), что первично ядро или glibc.
>Хочеться оргументированный ответ чем плох С++ для ядра линукса.Linux creator Linus Torvalds joined in to explain:
"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: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."
нифига не выйдет... ключевые слова С++ использованы как переменные и тп в коде ядра в контексте С. Была попытка зачистить ядро от этого и были патчи для поддержки С++, но это не прижилось... упертая ретроградгость девелоперов ядра... я покрутил эти патчи , но на последние ядра это все прикручивать и создавать свой дистрибутив ради С++ в своих драйверах это перебор...
>и были патчи для поддержки С++, но это не прижилось... упертая
>ретроградгость девелоперов ядра...c++ в ядре на самом деле не нужен. Мне жаль тех кто этого не понимает. Подумайте почему ядро не может быть написано на интерпретируемом языке. С++ практически тоже самое.
stl в ядре - тоже ржака. buffer.push_back() в обработчике прерывания собрались применять?
мне там не нужен stl. мне там нужны просто классы. даже эксепшен хандлинг не нужен... мне просто надо получить стабильный код драйвера через framework, учитывая постоянные мутации ядра. Кроме этого я кросс девелопер драйверов. Хочу общий код драйвера для windows и linux. Сейчас это получается только на уровне библиотек, хотя логически код дров и получается общий...
причем я не настаиваю на использовании С++ в ядре. Я хочу чтобы просто убрали искусственное ограничение на использование С++,а дальше уж как пойдет...народ сам решит.
>Linux creator Linus Torvalds...Мнение Торвальдса мне известно, хотельсь мнение вменяемых людей узнать.
>В дравере!? STL контейнеры!? ... в стране нехватка дворников - меняй профессию!
Если не знаю чего-либо - буду разбираться. Менять профессию - не мой путь.
>Ты сам приводил: << Мы все знаем чт...
Ага, сам. Понравилось?
>нифига не выйдет... ключевые слова С++ использованы как переменные и тп в коде ядра в контексте С.
Спосибо, не подумал об этом.
>Подумайте почему ядро не может быть написано на интерпретируемом языке.
Ну ты сравнил С++ с интерпретируемым языком. С++ практически не уступает С.
>stl в ядре - тоже ржака. buffer.push_back() в обработчике прерывания собрались применять?
Нет не в обработчике прерываний. Минус STL вижу в том что возможны в процессе работы динамическое выделение памяти. Это надо учитывать при написании кода. Бороться с этим можно.
-----
В общем С++ как вариант для драйвера больше не рассматриваю.
Ни одного мнения за плюсы нет.
Всем большое спасибо!!!
>С++ практически не уступает С.И java не уступает C ))
Но и java и php и c++ не могут жить без рантайм библиотек. А рантайм библиотеке с++ в ядре совсем не рады.Реализация шаблонов вызывает рост экспортируемых имён.
А зачем нужны классы если не нужны исключения или виртуальные функции? Ты видел как пишеться объектный код на C в ядре linux?>В общем С++ как вариант для драйвера больше не рассматриваю.
+1
>Здравствуйте!
>
>Пишу драйвер для ucLinux и хочу реализовать драйвер на С++, а не
>на С.Основное препятствие использования С++ в ядре (в частности в драйвере). То что ядро оперирует такими понятиями как данные (биты и байты) и действия над ними , С++ оперирует понятиями объекты и взаимодействие объектов. Совместить ни как не получится.
То есть в лучшем случаи создашь С код и откомпилируешь его С++ компилятором.
Да и потом С++ компилятор утяжеляет исполняемый код, а для ядра скорость выполнения и размер кода имеет первоочередное значение. В силу того что делаешь драйвер для uclinux.
А данный дистрибутив в основном применяют на микроконтроллерах.P.S. Сам ставил ucLinux на микроконтроллеры и драйвера писал, желание сделать их на С++ не возникало.
Народ, прежде чем наезжать на плюсы, хочется спросить - а вы с ним работали? Насколько сложные проекты? По большинству ответов видно, что уровень владения языком С++ на уровене "знаю человека, троюродный брат которого через плечо заглядывал начинающему программисту на С++".В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS. Написана на плюсах (ес-но, есть места на ассмемблере - без этого никак). Причем, эта операционка показывает одни из лучших параметров (размер кода, ресурсы, реакция на события) в своем классе.
Вобщем, кто-то может аргументы привести, чем ембеддед плюсы хуже си?
Теперь по делу: писать драйвера на плюсах - плохая идея, но это не из-за того, что язык плохой, а из-за того, что сама система Linux под это не заточена (причем такое ощущение - сделано все, чтобы плюсы в кернеле не использовали).
>В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS.
>Написана на плюсах (ес-но, есть места на ассмемблере - без этого
>никак). Причем, эта операционка показывает одни из лучших параметров (размер кода,
>ресурсы, реакция на события) в своем классе.И какие же возможности c++ используются? Наследование, виртуальные методы, шаблоны, обработка исключений?
>Вобщем, кто-то может аргументы привести, чем ембеддед плюсы хуже си?
Что такое «ембеддед плюсы»?
>И какие же возможности c++ используются? Наследование, виртуальные методы, шаблоны, обработка исключений?
>Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме RTTI.
>Что такое «ембеддед плюсы»?Ну не совсем точно выразился (название Embedded C++ уже зарезервировано)) ). Ладно, чем хуже _разумно_ писать на Си++, чем на Си?
>Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме
>RTTI.Наследование без виртуальных методов и исключений - обычное вкладывание одной структуры данных в другую, прекрасно пишется и на C.
Шаблоны раздувают код и усложняют линковку. И так процедура загрузки модуля в ядро не тривиальная, а уж если использовать шаблоны то будет вообще кошмар. И самое печальное, что глобальное пространство имён загадится шаблонами похлеще авгиевых конюшен.
>Ну не совсем точно выразился (название Embedded C++ уже зарезервировано)) ). Ладно,
>чем хуже _разумно_ писать на Си++, чем на Си?Ты читал что написано выше?
Если разумно писать на C++ по твоему, это означает не пользоваться его основными возможностями, то я считаю, лучше в таком случае чистый C.
>>Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме
>>RTTI.
>
>Наследование без виртуальных методов и исключений - обычное вкладывание одной структуры данных
>в другую, прекрасно пишется и на C.Виртуальные методы не используются в данном проекте (scmRTOS), но активно используются в других. Кстати, а чем они вас так напрягают? В ядре линукса они тоже (в сишном виде) используются.
>Шаблоны раздувают код и усложняют линковку. И так процедура загрузки модуля в
>ядро не тривиальная, а уж если использовать шаблоны то будет вообще
>кошмар. И самое печальное, что глобальное пространство имён загадится шаблонами похлеще
>авгиевых конюшен.Шаблоны раздувают код? Имеете в виду, что будет множество инстанцированний? Опять же - зависит от кривизны рук программиста. Кстати, а дефайны не раздувают? )))))
И в чем сложность линковки? (хотя бы - лично для вас?)
Про загаживаение пространства имен - не смешите - в сишных проектах оно загажено еще сильнее глобальными переменными. С++ как раз и задумывался как язык инкапсулирующий данные и методы их обработки
В качестве примера удобства использования - напишите мне аналог на Сиclass CCriticalSect
{
inline CCriticalSect(){int_disable();}
inline ~CCriticalSect(){int_enable();}
};
* * *void func(int a)
{
CCriticalSect clCS_;switch (a)
{
case (A0):
{
* * *
return;
}case (A1):
{
* * *
return;
}case (A2):
{
* * *
return;
}case (A3):
{
* * *
return;
}
case (A4):
{
* * *
return;
}}
}
Ес-но код выше прошу не обсуждать - это тупой пример функции в несколькими точками выхода. Тут главное суть - удобство факта существования конструктора / деструктора.Или создание объекта до main()
class ClassMainWarpper
{
ClassMainWarpper()
{
printf("Before main\n");
}~ClassMainWarpper()
{
printf("After main\n");
}
};ClassMainWarpper clMW;
void main()
{
printf("main\n");
}
>Тут главное суть - удобство факта существования конструктора
>/ деструктора.Если и удобно оно, то только для автоматических переменных. А учитывая, что автоматических переменных в ядре нет (экономить стек надо, в стеке только указатели на структуры), никакого удобства не получается. Явный new + delete ничем не лучше функций init + fini.
>Или создание объекта до main()В ядре нет main. И порядок создание объектов в ядре linux очень чёткий, понятный и контролируемый.
>Шаблоны раздувают код? Имеете в виду, что будет множество инстанцированний? Опять
>же - зависит от кривизны рук программиста. Кстати, а дефайны не
>раздувают? )))))Макросы раздувают, но они не вносят проблемы линковки. В последнее время всё чаще используются inline функции.
>И в чем сложность линковки? (хотя бы - лично для вас?)
В том что линковщик должен определить что это шаблон, и не нервничать встретив дубликата при линковке, а просто его потерять. Это сложность, не приемлемая во время линковки (загрузки) загружаемого модуля ядра.
>Про загаживаение пространства имен - не смешите - в сишных проектах оно
>загажено еще сильнее глобальными переменными. С++ как раз и задумывался как
>язык инкапсулирующий данные и методы их обработкиСлышал звон. Писать плохо можно и на С. Посмотри сколько глобальных переменных и функций в linux. Почти всё скрыто статиками. С шаблонами такие выкрутасы не прокатят. И классы с методами и namespace всплывут в глобальной области имён, дикими префиксами.
В ядре однозначно лучше убрать статиком, чем прятать за префиксом.
>видно, что уровень владения языком С++ на уровене "знаю человека, троюродный брат которогоА ниже - Ваш аргумент в русле "слышал от человека про реальную ос на плюсах -- сказыал всех делает по параметру чего-то там в носу"? Хорошо, что Вы внесли Конструктифф в эту безобразную перебранку, Спасибо!
>В качестве примера хороших разработок - можете глянуть embedded RTOS - ScmRTOS.
>Написана на плюсах (ес-но, есть места на ассмемблере - без этого
>никак). Причем, эта операционка показывает одни из лучших параметров (размер кода,
>ресурсы, реакция на события) в своем классе.
>А ниже - Ваш аргумент в русле "слышал от человека про реальную
>ос на плюсах -- сказыал всех делает по параметру чего-то там
>в носу"? Хорошо, что Вы внесли Конструктифф в эту безобразную >перебранку,Почему же? Не только слышал, но и использовал в своих работах. За что огромное спасибо автору. Кстати, ее многие железячники на электрониксе пользуют..
>Спасибо!Пожалуйста :)
Я донести пытаюсь - что и на плюсах можно писать быстрые, качественные приложения, ничем не уступающие коду на си. А то, что эта возможность зарублена в линуксе - это его минус
Дело не в скорости итп... основное это возможность изящно "стабилизировать" API ядра посредством разноообразных фрэймворков для драйверов, не загубив гибкости развития... но похоже пока у энтузиастов хватает сил ползать по всему коду драйвероа и патчить его под новые API...
>Дело не в скорости итп... основное это возможность изящно "стабилизировать" API ядра
>посредством разноообразных фрэймворков для драйверов, не загубив гибкости развития... но похоже
>пока у энтузиастов хватает сил ползать по всему коду драйвероа
>и патчить его под новые API...Не понял что ты имеешь ввиду. Какие фреймворки???
Исходная задача такая была: есть микросхема для работы с потоками E1, есть ucLinux, надо реализовать протокол канального уровня. Протокол канального уровня и реализуеться в виде драйвера. Таким образом драйвер пишеться с нуля и привязан к микросхеме.
Был вопрос в выборе языка C или С++. Я преверженец С++ вот и интересовался как обстоит дело с С++ в ядре.Пэ.Эс. Если у тебя есть пара фреймфорков реализующих телекоммуникационные протоколы, дай плиз :-)
это было общее рассуждение... я тоже C++ больше люблю. и очень не люблю править драйвера с выходом новых ядер тк функции ядра меняются. Предпочел бы что-то типа numega driver studio иметь в linux. C телекоммуникациями никак не связан... www.lcard.ru мой профиль....
Какой вы страшный флейм устроили. При написании LKM главное что, чтобы весь экспорт ядро распознало, и чтобы весь импорт ядро предоставило. А пиши хоть на испанском, лишь бы вменяемый компилятор был. С экспортом просто, с импортом сложнее, но совсем не в плане STL, exceptions и RTTI, а в плане того, что они потащат за собой целую libstdc++ и libgcc, которые, в свою очередь, зависимы от glibc, и там начинается гемор. Но при желании это можно порешать... Только дрова жирные получатся, C транслируется в asm практически линейно, а C++ требует обширной библиотечной поддержки...