https://www.opennet.ru/openforum/vsluhforumID9/8226.html Здравствуйте!<br><br>Пишу драйвер для ucLinux и хочу реализовать драйвер на С++, а не на С.<br>Возникла проблема линковки - линковщик не понимает объектные файлы созданные g++.<br>В частности имены функций в объектных файлах скомпилированных gcc и g++ создаються по-разному.<br>gcc: _funcname<br>g++: __Z7funcnamev<br><br>Если в .cpp файле функцию заключить в extern "C" { void funcname() {} }, то имена ф-ии в объектниках g++ делает как и gcc, однако по прежнему<br>: undefined reference to `funcname'.<br><br>Вопросы:<br>1) как сделать чтобы код С++ нормально собирался с ядром линукса?<br>2) какие подводные камни возможны при использовании С++ в ядре линкса?<br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#31 Tue, 02 Jun 2009 20:59:16 GMT Какой вы страшный флейм устроили. При написании LKM главное что, чтобы весь экспорт ядро распознало, и чтобы весь импорт ядро предоставило. А пиши хоть на испанском, лишь бы вменяемый компилятор был. С экспортом просто, с импортом сложнее, но совсем не в плане STL, exceptions и RTTI, а в плане того, что они потащат за собой целую libstdc++ и libgcc, которые, в свою очередь, зависимы от glibc, и там начинается гемор. Но при желании это можно порешать... Только дрова жирные получатся, C транслируется в asm практически линейно, а C++ требует обширной библиотечной поддержки...<br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#30 Wed, 13 May 2009 07:11:32 GMT это было общее рассуждение... я тоже C++ больше люблю. и очень не люблю править драйвера с выходом новых ядер тк функции ядра меняются. Предпочел бы что-то типа numega driver studio иметь в linux. C телекоммуникациями никак не связан... www.lcard.ru мой профиль....<br><br><br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#29 Wed, 13 May 2009 02:34:46 GMT &gt;Дело не в скорости итп... основное это возможность изящно "стабилизировать" API ядра <br>&gt;посредством разноообразных фрэймворков для драйверов, не загубив гибкости развития... но похоже <br>&gt;пока у энтузиастов хватает сил ползать по всему коду драйвероа <br>&gt;и патчить его под новые API... <br><br>Не понял что ты имеешь ввиду. Какие фреймворки???<br>Исходная задача такая была: есть микросхема для работы с потоками E1, есть ucLinux, надо реализовать протокол канального уровня. Протокол канального уровня и реализуеться в виде драйвера. Таким образом драйвер пишеться с нуля и привязан к микросхеме.<br>Был вопрос в выборе языка C или С++. Я преверженец С++ вот и интересовался как обстоит дело с С++ в ядре.<br><br>Пэ.Эс. Если у тебя есть пара фреймфорков реализующих телекоммуникационные протоколы, дай плиз :-)<br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#28 Tue, 12 May 2009 10:38:16 GMT Дело не в скорости итп... основное это возможность изящно "стабилизировать" API ядра посредством разноообразных фрэймворков для драйверов, не загубив гибкости развития... но похоже пока у энтузиастов хватает сил ползать по всему коду драйвероа и патчить его под новые API...<br><br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#27 Thu, 07 May 2009 10:04:18 GMT &gt;Шаблоны раздувают код? Имеете в виду, что будет множество инстанцированний? Опять <br>&gt;же - зависит от кривизны рук программиста. Кстати, а дефайны не <br>&gt;раздувают? ))))) <br><br>Макросы раздувают, но они не вносят проблемы линковки. В последнее время всё чаще используются inline функции.<br><br>&gt;И в чем сложность линковки? (хотя бы - лично для вас?) <br><br>В том что линковщик должен определить что это шаблон, и не нервничать встретив дубликата при линковке, а просто его потерять. Это сложность, не приемлемая во время линковки (загрузки) загружаемого модуля ядра.<br><br>&gt;Про загаживаение пространства имен - не смешите - в сишных проектах оно <br>&gt;загажено еще сильнее глобальными переменными. С++ как раз и задумывался как <br>&gt;язык инкапсулирующий данные и методы их обработки <br><br>Слышал звон. Писать плохо можно и на С. Посмотри сколько глобальных переменных и функций в linux. Почти всё скрыто статиками. С шаблонами такие выкрутасы не прокатят. И классы с методами и namespace всплывут в глобальной области имён, дикими префиксами.<br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#26 Wed, 06 May 2009 09:42:39 GMT &gt;Тут главное суть - удобство факта существования конструктора <br>&gt;/ деструктора. <br><br>Если и удобно оно, то только для автоматических переменных. А учитывая, что автоматических переменных в ядре нет (экономить стек надо, в стеке только указатели на структуры), никакого удобства не получается. Явный new + delete ничем не лучше функций init + fini.<br><br><br>&gt;Или создание объекта до main() <br><br>В ядре нет main. И порядок создание объектов в ядре linux очень чёткий, понятный и контролируемый.<br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#25 Wed, 06 May 2009 04:15:20 GMT Ес-но код выше прошу не обсуждать - это тупой пример функции в несколькими точками выхода. Тут главное суть - удобство факта существования конструктора / деструктора.<br><br>Или создание объекта до main()<br><br>class ClassMainWarpper<br>{<br> ClassMainWarpper()<br> {<br> printf("Before main\n");<br> }<br><br> ~ClassMainWarpper()<br> {<br> printf("After main\n");<br> }<br>};<br><br>ClassMainWarpper clMW;<br><br><br>void main()<br>{<br> printf("main\n");<br>}<br><br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#24 Wed, 06 May 2009 03:02:16 GMT В качестве примера удобства использования - напишите мне аналог на Си<br><br>class CCriticalSect<br>{<br> inline CCriticalSect(){int_disable();}<br> inline ~CCriticalSect(){int_enable();}<br>};<br><br><br>* * * <br><br>void func(int a)<br>{<br> CCriticalSect clCS_;<br><br> switch (a)<br> {<br> case (A0):<br> {<br> * * *<br> return;<br> }<br><br> case (A1):<br> {<br> * * *<br> return;<br> }<br><br> case (A2):<br> {<br> * * *<br> return;<br> }<br><br> case (A3):<br> {<br> * * *<br> return;<br> }<br><br><br> case (A4):<br> {<br> * * *<br> return;<br> }<br><br> }<br><br><br>}<br> https://www.opennet.ru/openforum/vsluhforumID9/8226.html#23 Wed, 06 May 2009 02:58:02 GMT &gt;&gt;Наследования, шаблоны. В своих проектах (на том же BF537) использую все, кроме <br>&gt;&gt;RTTI. <br>&gt;<br>&gt;Наследование без виртуальных методов и исключений - обычное вкладывание одной структуры данных <br>&gt;в другую, прекрасно пишется и на C. <br><br>Виртуальные методы не используются в данном проекте (scmRTOS), но активно используются в других. Кстати, а чем они вас так напрягают? В ядре линукса они тоже (в сишном виде) используются. <br><br>&gt;Шаблоны раздувают код и усложняют линковку. И так процедура загрузки модуля в <br>&gt;ядро не тривиальная, а уж если использовать шаблоны то будет вообще <br>&gt;кошмар. И самое печальное, что глобальное пространство имён загадится шаблонами похлеще <br>&gt;авгиевых конюшен. <br><br>Шаблоны раздувают код? Имеете в виду, что будет множество инстанцированний? Опять же - зависит от кривизны рук программиста. Кстати, а дефайны не раздувают? )))))<br><br>И в чем сложность линковки? (хотя бы - лично для вас?)<br>Про загаживаение пространства имен - не смешите - в сишных проектах оно загажено еще сильнее глобальными перем