KP>обычный gdb интегрируется в Eclipse и SlickEdit
О да, спасибо, что напомнил. Вот на прошлой неделе после апдейта моей рабочей машины до CentOS 6.3 произошел конфуз — Eclipse CDT отказался запускать debug. Со ругательствами на питон, и на maintenance mode off/on. Почти целый день ушел, чтобы всё вернуть "как было".
Потому что — сначала на другой машине проверил, "всё работает". Потом гуглил, долго, усиленно гуглил — у всех в итоге "обновите Eclipse, обновите GDB, обновите, обновите". Обновлял во всех возможных вариантах, даже заново Eclipse CDT качнул (мой уж сильно засорился хламом разным, даже стартовал медленно). Обновленный gdb 7.2 (а выше redhat'ы не выпустили, однако) также не взлетел. Качнул новый gdb, собрал, — пропал pretty-printing of STL containers. Загуглил и это, сделал всё по инструкциям — не работает. Уже и не помню, какая комбинация из каких инструкций помогла, почти всё стало "как было", за исключением std::map, который всё так же печатается через ж..у, и еще там какие-то несущественные мелочи.
А так, да, "gdb интегрируется в Eclipse CDT" (C)
Re[9]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>ROTFL. Вот уж рвотную массу под названием MSDN лучше вообще не вспоминать. Мало того, что там нет нормального поиска (Гугл лучше справляется!), так ещё и полно мест, которые просто недокументированы. Особенно в ядерном программировании. R>доказательства будут, или точно такое же неподтвержденное заявление как существование в природе "питающихся дошираком системщиков, пишущих говнодрайвера на Винде за штукобаксов в месяц" ?
Что? Про недокументированные функции ядерного API? Так это любой драйверописатель знает.
Вот тебе целый сайт из них: http://undocumented.ntinternals.net/
R>>>wdk — нет. типа сорцов ядра должно быть достаточно, угу-угу три раза C>>WDK — это такой непонятный уродец, где даже нет примеров исходников нормальной современной FS или графического драйвера? R>я с графическими драйверами дел не имел никогда, но про файловые системы мнение имею.
Ну так где в WDK примеры хорошей FS?
R>из той кучи, что зачем-то включена в ядро linux, пользоваться можно крайне ограниченным количеством: R> — jfs — написана IBM R> — xfs — написана Silicon Graphics
Ну и? Кстати, обе уже давно считаются больше legacy из-за множества ограничений.
R> — zfs — написана sun
Сторонняя, в mainline ядре нет и не будет из-за ограничений.
R>а свое-то у вас есть чо-нть ?
Btrfs и ext4 — сделаны исключительно для Линукса. Кластерные FS: OCFS2, GFS2, Ceph. Флешковые файловые системы: F2FS, JFFS2.
Вот уж с файловыми системами Винде стоит заткнуться в тряпочку, привязать камни к ногам и утопиться. Виндовый файловый фэйловый стек часто работает в сотни раз медленнее Линуксового.
Sapienti sat!
Re[17]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
V>>The balls are the same. R>я искренне поражен встретить столь подробный ответ по делу на русскоязычном ресурсе R>но все же это не совсем так R>линукс запрещает прерывания насовсем (причем local_irq_disable появился ЕМНИП только в ядре 2.6)
1) "Только в ядре 2.6" означает "вот уже как 10 лет".
2) Неверно.
Обычный спинлок не запрещает ВООБЩЕ ничего, часто даже preemption потока (см. в RT-версии). Какие проблемы-то?
R>как вы и сказали это больше всего влияет на однопроцессорные машины, с ростом числа камней значение этого решения падает (при правильном равномерном распределении прерываний на все доступные камни)
Винда на многопроцессорных машинах вообще сосёт. До недавнего времени она умирала на 64 ядрах, сейчас живёт на чуть большем количестве за счёт кластеризации ядер в несколько групп.
Sapienti sat!
Re[13]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>В Линуксе нет бреда с IRQL. R>очевидно потому что они irql не осилили R>по мне так значительно более бредово запрещать вообще все прерывания на spinlock
Уже ответил. Spinlock может вообще ничего не запрещать.
C>> (как, в Виндоусе до сих пор нет нормального отладчика блокировок?!). R>опция Deadlock Detection в driver verifier
Выделено.
C>>А зачем сервер? У нас уже 100500 лет есть скрипт из 5 строк, который достаёт по ID билда отладочные символы из файлопомойки и исходники из SCM. R>это будет работать только если вы не даете пользователю пересобрать ядро самостоятельно (что ай-яй-яй и столлман запретил) или для каждого пересобранного ядра вам нужно иметь symbol info где-нть на вашей стороне
Если пользователь пересобирает ядро сам, то у него будут отладочные символы. И нам от него придёт, скорее всего, фотография kernel oops'а в которой будет символический stack trace.
Sapienti sat!
Re[7]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>хотя у них не только msdn — у них в сущности ничего нет R>аналога visual studio — нет R>wdk — нет. типа сорцов ядра должно быть достаточно, угу-угу три раза R>удобного ядерного отладчика — тоже нет R>да чо там ядерного — обычный gdb больше всего похож на debug.com 80ых годов
Вот и выросло поколение
Re[14]: Написание драйверов под Linux на С, стоит ли начинать?
C>Уже ответил. Spinlock может вообще ничего не запрещать.
кол-во вызовов spin_lock_irqsave в ядре сами подсчитаете ?
C>>> (как, в Виндоусе до сих пор нет нормального отладчика блокировок?!). R>>опция Deadlock Detection в driver verifier C>Выделено.
более обоснованных претензий хотелось бы услышать
C>Если пользователь пересобирает ядро сам, то у него будут отладочные символы. И нам от него придёт, скорее всего, фотография kernel oops'а в которой будет символический stack trace.
я и не сомневался
в случае же с виндой у нас будут символы и мы сможем спокойно посмотреть где оно упало. и что характерно — фотокарточек никаких не нужно
паранойя не болезнь, а критерий профпригодности
Re[10]: Написание драйверов под Linux на С, стоит ли начинать?
C>Что? Про недокументированные функции ядерного API? Так это любой драйверописатель знает. C>Вот тебе целый сайт из них: http://undocumented.ntinternals.net/
ничего что почти все описанные там ф-ции есть в книжке "Windows NT/2000 Native API Reference", изданной аж в 2000 году ?
C>Ну так где в WDK примеры хорошей FS?
критерии "хорошести" озвучьте пожалуйста
C>Btrfs и ext4 — сделаны исключительно для Линукса.
поэтому очевидно гугл выдает 239 тысяч страниц на запрос "btrfs problems" (причем третья ссылка прямо говорит нам: "Do not use Btrfs!") и 1240000 на "ext4 problems" ?
C>Виндовый файловый фэйловый стек часто работает в сотни раз медленнее Линуксового.
(зевая) революционное чутье, да ?
паранойя не болезнь, а критерий профпригодности
Re[14]: Написание драйверов под Linux на С, стоит ли начинать?
R>>там выше т-щ Cyberax столь же уверенно упоминал о всяких левых проектах, которые в ядро не включены, но должны чо-то кому-то доказать C>Можно ссылку где я про это говорил?
а как же — у нас все ходы записаны
вот тут
например было сказано:
C>в Линуксе есть полно статических верификаторов. К примеру, для подсистемы RCU (Read-Copy-Update) был написан проект, который нашёл ошибки в куче других параллельных структур
ни названий тех верификаторов, ни имен файлов в дереве сорцов linux kernel — у нас просто есть. мамой клянусь. верьте нам (c)
паранойя не болезнь, а критерий профпригодности
Re[11]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>Что? Про недокументированные функции ядерного API? Так это любой драйверописатель знает. C>>Вот тебе целый сайт из них: http://undocumented.ntinternals.net/ R>ничего что почти все описанные там ф-ции есть в книжке "Windows NT/2000 Native API Reference", изданной аж в 2000 году ?
Ничего, что мы говорим про MSDN?
C>>Ну так где в WDK примеры хорошей FS? R>критерии "хорошести" озвучьте пожалуйста
Современная, быстрая, понятная.
C>>Btrfs и ext4 — сделаны исключительно для Линукса. R>поэтому очевидно гугл выдает 239 тысяч страниц на запрос "btrfs problems" (причем третья ссылка прямо говорит нам: "Do not use Btrfs!") и 1240000 на "ext4 problems" ?
Ничего, что на "NTFS Problems" выводится 7,530,000 страниц?
По факту, ext4 вполне стабильна. А btrfs уже почти стабильна — в ней столько новых фич и вполне понятно, что первые годы она была не самая стабильная.
C>>Виндовый файловый фэйловый стек часто работает в сотни раз медленнее Линуксового. R>(зевая) революционное чутье, да ?
Неа. Benchmark'и. Реально в сотни и тысячи раз медленнее.
Sapienti sat!
Re[15]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>>>там выше т-щ Cyberax столь же уверенно упоминал о всяких левых проектах, которые в ядро не включены, но должны чо-то кому-то доказать C>>Можно ссылку где я про это говорил? R>а как же — у нас все ходы записаны R>вот тут
например было сказано:
И?
C>>в Линуксе есть полно статических верификаторов. К примеру, для подсистемы RCU (Read-Copy-Update) был написан проект, который нашёл ошибки в куче других параллельных структур R>ни названий тех верификаторов, ни имен файлов в дереве сорцов linux kernel — у нас просто есть. мамой клянусь. верьте нам (c)
Шок! Сенсация! Исходников gcc в mainline ядре тоже нет.
Ты разделяй инструменты и сам код ядра.
Sapienti sat!
Re[7]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, pkl, Вы писали:
.
__>>И что, и жилье в эту сумму входит? И что, и дальше так и планируете? И т.д. и т.п. pkl>Ну не все ведь брошены на произвол судьбы без квартир, оставленных им в наследство бабушками.
Вот и я про это. "Живу на 100 рублей" и "живу на 100 рублей и наследство бабушки" — не одно и то же.
Re: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, GRIENDERS, Вы писали:
GRI>Работаю c C около года, вернее, он как хобби. Так в основном на ruby и c#. GRI>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C?
в винде дрова пишут зачастую для того, чтобы получить доступ к недрам системы. в никсах с этим проще. если ты рут, то хоть читай память ядра, хоть работай с портами в/в. а потому в никсах драйвера пишут в основном для управления оборудованием. а оно сильно разное. драйвер под RAID сильно отличается от драйвера под видюху. узость специализации усложняет поиски работы, с другой стороны она упрощает миграцию, т.к. своих специалистов найти сложно (в силу узости).
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[12]: Написание драйверов под Linux на С, стоит ли начинать?
C>Ничего, что мы говорим про MSDN?
в мсдн кстати тоже есть описания некоторых из этих ф-ций
C>>>Ну так где в WDK примеры хорошей FS? R>>критерии "хорошести" озвучьте пожалуйста C>Современная, быстрая, понятная.
"за все хорошее и против всего плохого"
ну отличные критерии, чо. современная — это которая в кедах и на ruby написана, я полагаю ?
C>Ничего, что на "NTFS Problems" выводится 7,530,000 страниц?
а теперь можно прикинуть число инсталляций каждой из этих FS, после чего считать ntfs образцом устойчивости, ага
C>btrfs уже почти стабильна
бгг
почти стабильная файловая система, да
C>Неа. Benchmark'и. Реально в сотни и тысячи раз медленнее.
я названий или пруфов каких-нть дождусь от вас ?
паранойя не болезнь, а критерий профпригодности
Re[15]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>Уже ответил. Spinlock может вообще ничего не запрещать. R>кол-во вызовов spin_lock_irqsave в ядре сами подсчитаете ?
13354 штук в 3.6.9.
Теперь требую посчитать количество участков с поднятым IRQL в Винде? Как, это невозможно?
Фу! Отстой!
C>>>> (как, в Виндоусе до сих пор нет нормального отладчика блокировок?!). R>>>опция Deadlock Detection в driver verifier C>>Выделено. R>более обоснованных претензий хотелось бы услышать
А зачем?
C>>Если пользователь пересобирает ядро сам, то у него будут отладочные символы. И нам от него придёт, скорее всего, фотография kernel oops'а в которой будет символический stack trace. R>я и не сомневался R>в случае же с виндой у нас будут символы и мы сможем спокойно посмотреть где оно упало. и что характерно — фотокарточек никаких не нужно
А если пользователь сам пересоберёт драйвер? Упс.
Sapienti sat!
Re[13]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>Ничего, что мы говорим про MSDN? R>в мсдн кстати тоже есть описания некоторых из этих ф-ций
Не-не. MSDN — это же полная Библия. Она делает навыки гугления излишними для виндового программиста. Ведь если чего-то нет в MSDN — то это не нужно, а если оно есть в MSDN — то Гугл излишний.
C>>Современная, быстрая, понятная. R>"за все хорошее и против всего плохого" R>ну отличные критерии, чо. современная — это которая в кедах и на ruby написана, я полагаю ?
Необязательно. К примеру, интересна была бы кластерная файловая система для Винды типа Ceph.
C>>btrfs уже почти стабильна R>бгг R>почти стабильная файловая система, да
Бггшить — это на форум куда-нибудь в другое место.
А теперь покажи мне любую (пусть и нестабильную) ФС для Винды, которая умеет делать разные уровни RAID на отдельные каталоги, позволяет делать атомарные snapshot'ы отдельных каталогов и файлов, позволяет динамически менять структуру хранилища, умеет посылать поток изменений по сети и т.д.
C>>Неа. Benchmark'и. Реально в сотни и тысячи раз медленнее. R>я названий или пруфов каких-нть дождусь от вас ? http://www.rsdn.ru/forum/philosophy/1753384.flat
C>Не-не. MSDN — это же полная Библия. Она делает навыки гугления излишними для виндового программиста. Ведь если чего-то нет в MSDN — то это не нужно, а если оно есть в MSDN — то Гугл излишний.
вы сейчас отвечаете на голоса в собственной голове — я нигде не утверждал что кроме msdn ничего больше не требуется
C>Необязательно. К примеру, интересна была бы кластерная файловая система для Винды типа Ceph.
тоже "почти стабильная" ?
C>http://www.rsdn.ru/forum/philosophy/1753384.flat
— сошлюсь на себя самого.
уже ближе к делу
2006 год — это на какой версии windows все тестировалось ? vista ? 32/64 бита ? и что должно означать C>тестовая виндовая намного машина лучше линуксовой
лучше — это дороже ?
извините, но это не бенчмарк
паранойя не болезнь, а критерий профпригодности
Re[16]: Написание драйверов под Linux на С, стоит ли начинать?
C>13354 штук в 3.6.9.
отлично
это означает что несколько тысяч раз в коде linux kernel запрещает прерывания, хотя в это время некоторые из них вполне могли бы быть обработаны, если бы использовался механизм irql
могу еще про giant lock напомнить, удаленный только в 2011 кажется
C>А если пользователь сам пересоберёт драйвер? Упс.
а вот в этом и прелесть closed source — никто кроме вас ваш драйвер не соберет. и соотв-но версий драйвера и гемора с отладкой будет сильно меньше
паранойя не болезнь, а критерий профпригодности
Re[17]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>13354 штук в 3.6.9. R>отлично R>это означает что несколько тысяч раз в коде linux kernel запрещает прерывания,
Это означает, что в коде Линукса для 30 с чем-то платформ есть 13 тысяч мест, где блокируются прерывания со спинлоком.
R>хотя в это время некоторые из них вполне могли бы быть обработаны, если бы использовался механизм irql
В Линуксе есть механизмы, которые позволяют делать ровно всё то же самое (и даже больше):
1) PASSIVE — это обычные spinlock'и и ядерные мьютексы.
2) APC — то же самое. Один фиг в Винде он бесполезен.
3) DISPATCH — блокировка планировщика для этого потока и, возможно, локальных прерываний.
R>могу еще про giant lock напомнить, удаленный только в 2011 кажется
В 2010-м. И что? Он реально перестал мешать уже в районе 2006-го года, когда его удалили практически со всех горячих путей.
C>>А если пользователь сам пересоберёт драйвер? Упс. R>а вот в этом и прелесть closed source — никто кроме вас ваш драйвер не соберет. и соотв-но версий драйвера и гемора с отладкой будет сильно меньше
Да-да. Прелесть в том, что пользователю проще нафиг выкинуть проприетарное Г. и написать своё, открытое и приятное на Линуксе. Мы так поступили с парой софтин из-за того, что на Винде их на кластерах нормально не запустить.
Sapienti sat!
Re[15]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>Не-не. MSDN — это же полная Библия. Она делает навыки гугления излишними для виндового программиста. Ведь если чего-то нет в MSDN — то это не нужно, а если оно есть в MSDN — то Гугл излишний. R>вы сейчас отвечаете на голоса в собственной голове — я нигде не утверждал что кроме msdn ничего больше не требуется
Цитирую:
линуксоиду _жизненно_ необходимо прокачивать скилл гугления. удобоваримого аналога msdn'а нет и близко, хотя попытки и предпринимаются.
C>>Необязательно. К примеру, интересна была бы кластерная файловая система для Винды типа Ceph. R>тоже "почти стабильная" ?
Ceph вполне стабилен и удобен. И таки на Винде аналогов не видно.
C>>http://www.rsdn.ru/forum/philosophy/1753384.flat
— сошлюсь на себя самого. R>уже ближе к делу R>2006 год — это на какой версии windows все тестировалось ? vista ? 32/64 бита ? и что должно означать
WinXP.
C>>тестовая виндовая намного машина лучше линуксовой R>лучше — это дороже ? R>извините, но это не бенчмарк
Я его проводил на одинаковых машинах несколько раз за эти годы. Винда примерно так же тормозит до сих пор — абсолютно убогая масштабируемость файловой системы.
Собственно, это и неудивительно. Фэловый стек в Винде писали кретины, и до сих пор не могут его нормально переделать. Я уже как-то об этом писал: http://www.rsdn.ru/forum/flame.comp/3497317.1
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, GRIENDERS, Вы писали:
GRI>>Работаю c C около года, вернее, он как хобби. Так в основном на ruby и c#. GRI>>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? М>в винде дрова пишут зачастую для того, чтобы получить доступ к недрам системы. в никсах с этим проще. если ты рут, то хоть читай память ядра, хоть работай с портами в/в. а потому в никсах драйвера пишут в основном для управления оборудованием. а оно сильно разное. драйвер под RAID сильно отличается от драйвера под видюху. узость специализации усложняет поиски работы, с другой стороны она упрощает миграцию, т.к. своих специалистов найти сложно (в силу узости).
