GRI>Работаю c C около года, вернее, он как хобби. Так в основном на ruby и c#. GRI>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
Вперед в прошлое? C это язык разработанный в 70х и имеющий ограниченную область применимости — высокие нагрузки, системные вещи и драйверы. Области это низкооплачиваемые (возможно кроме первой), недостатка специалистов нет. Вы явно заблуждаетесь что C сейчас очень востребован и хорошо оплачивается.
Re[10]: Написание драйверов под Linux на С, стоит ли начинать?
KP>eclipse + cdt — очень даже не плохая штука. особенно с учетом того, что в нем можно не только на C++, но и на Java и прочих приличных языках писать.
хм, java и "приличный язык" тут явно не сочетаются
anyway, он уже научился стартовать быстрее чем за пару минут и жрать хотя бы пару гигов памяти вместо 3-5 ?
R>>каталог help в wdk рулит значительно сильнее. ну и в msdn еще статьи KP>Похоже, дело во вкусе фламастеров Мне реально удобнее поглядеть на код функции и понять что нужно, плюс никаких "недокументированных" возможностей.
нет
например в коде linux ядра до сих пор нету даже простых аннотаций к прототипам ф-ций — например некую ф-цию не можно дергать на повышенном irql. отсюда проистекают всякие далекоидущие следствия вроде отсутствия статического verifier. да и просто driver verifier в ядре нет
понятия symbol packages/symbol server отсутствуют как класс. соотв-но дамп, присланный с машины в другом полушарии бесполезен чуть более чем полностью
и так далее, и тому подобное. так и живут в 80ых годах прошлого века
паранойя не болезнь, а критерий профпригодности
Re[12]: Написание драйверов под Linux на С, стоит ли начинать?
KP>Я драйверов пишу мало,поэтому именно эта часть меня мало заботит
а я как раз наоборот
и с точки зрения kernel/driver development linux проигрывает винде по всем критериям какие только возможны
паранойя не болезнь, а критерий профпригодности
Re[15]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>Здравствуйте, sysenter, Вы писали:
S>>Здравствуйте, redp, Вы писали:
C>>>>В Линуксе нет бреда с IRQL. R>>>очевидно потому что они irql не осилили R>>>по мне так значительно более бредово запрещать вообще все прерывания на spinlock
S>>Кто нибудь может популярно объяснить можно ли разрешать/запрещать irql на спинлоках и чем чревато? R>проще ознакомиться с матчастью я думаю
Откуда следует, что прерывания в win таки запрещаются Точнее, запрещаются на KeAcquireInterruptSpinLock() как и на spin_lock_irqsave(), в то время как KeAcquireSpinLock() и spin_lock() их не запрещают.
Дело в том, что если спинлок используется для синхронизации между вытесняемым потоком исполнения (это может быть ядерная нить, DPC, whatever) и Interrupt Service Routine (ISR), то не запрещать прерывания нельзя. В противном случае по приходу прерывания мы войдем в тот же спинлок еще раз, что приведет к самоблокировке (на самом деле можно не запрещать, нужно просто посылать ack в контроллер прерываний после отработки ISR, но данный подход имеет свои недостатки и в данных системах не используется).
В win текущий IRQL просто поднимается до уровня DIRQL, ассоциированным с нужным irq. Тут важно понимать различие между irq и IRQL: первое — это аппаратное прерывание, второе — абстракция, показывающая уровень исполнения; каждое irq отображается на определенный IRQL (см. табличку по ссылке выще). Так вот, поднятие текущего IRQL запрещает вытеснение всему, что находится на более низких IRQL, в том числе и менее приоритетным прерываниям. Так что прерывания запрещаются (хоть и частично). Более того, в разных версиях win отображение irq на DIRQL разное, поэтому заранее невозможно сказать, какие прерывания более приоритетны, а какие менее (меппинг описан у Руссиновича в windows internals).
В линуксе немного по-другому. Опустим вопросы эволюции способов обработки прерываний в threaded-модель.
В общем случае, если ядро вытесняемое и включен SMP, простой spin_lock() запрещает вытеснение + захватывает счетчик, а spin_lock_irqsave() дополнительно запрещает прерывания на текущем cpu. Если в конфиге ядра выключить SMP, то из реализации спинлоков уберется счетчик, а при выключении вытесняемости ядра — и запрещение вытеснения. Таким образом на UP non-preemptible ядре spin_lock() выродится полностью.
Как несложно заметить, в линуксе используется некий набор флагов, а в win — IRQL модель, т.е. тупо больше флагов Ноги у обоих решений растут от BSD-шного понятия spl, просто Дейв Каттлер обобщил его (и усложнил), а Линус и ко — редуцировали (и упростили). The balls are the same.
Re[3]: Написание драйверов под Linux на С, стоит ли начинать?
S>если несекрет почему S>вакансий под linux вроде бы больше
очевидно именно поэтому
любая школота может посмотреть сорец кернела и сляпать по быстрому всякое глючное, уронив попутно цены до привычного доширачного уровня
паранойя не болезнь, а критерий профпригодности
Re[6]: Написание драйверов под Linux на С, стоит ли начинать?
aik>линуксоиду _жизненно_ необходимо прокачивать скилл гугления. удобоваримого аналога msdn'а нет и близко, хотя попытки и предпринимаются.
щас вас закидают фанаты
хотя у них не только msdn — у них в сущности ничего нет
аналога visual studio — нет
wdk — нет. типа сорцов ядра должно быть достаточно, угу-угу три раза
удобного ядерного отладчика — тоже нет
да чо там ядерного — обычный gdb больше всего похож на debug.com 80ых годов
паранойя не болезнь, а критерий профпригодности
Re[7]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
aik>>линуксоиду _жизненно_ необходимо прокачивать скилл гугления. удобоваримого аналога msdn'а нет и близко, хотя попытки и предпринимаются. R>щас вас закидают фанаты
Я сам линукскернел нынче. Не фанат ни разу, но деньги зарабатываю этим.
R>хотя у них не только msdn — у них в сущности ничего нет
В гугле — тоннами навалено.
R>аналога visual studio — нет
Есть ровно то, что нужно. vim с плагинами или емакс дают нечто класса msvc6, после которого ничего удобоваримого ms так и не произвел.
R>wdk — нет. типа сорцов ядра должно быть достаточно, угу-угу три раза
Хм. Мне — хватает, с запасом.
R>удобного ядерного отладчика — тоже нет
gdb прекрасен.
R>да чо там ядерного — обычный gdb больше всего похож на debug.com 80ых годов
Да. Белые буквы на черном фоне. Даже на бумажную газету похоже.
Лучше скажи — зачем тут устраивать этот срач снова и снова? Мой поинт что чуваку надо уметь гуглить самому, если он хочет быть успешным линуксоидом. а кем быть — он уже решил, вроде. Ниша вполне себе неплохая.
Re[7]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
aik>>линуксоиду _жизненно_ необходимо прокачивать скилл гугления. удобоваримого аналога msdn'а нет и близко, хотя попытки и предпринимаются. R>щас вас закидают фанаты R>хотя у них не только msdn — у них в сущности ничего нет
ROTFL. Вот уж рвотную массу под названием MSDN лучше вообще не вспоминать. Мало того, что там нет нормального поиска (Гугл лучше справляется!), так ещё и полно мест, которые просто недокументированы. Особенно в ядерном программировании.
Приходится рыться в архивах списков рассылки.
R>аналога visual studio — нет
Для ядерного программирования он и не особо нужен.
R>wdk — нет. типа сорцов ядра должно быть достаточно, угу-угу три раза
WDK — это такой непонятный уродец, где даже нет примеров исходников нормальной современной FS или графического драйвера?
Закопайте обратно.
R>удобного ядерного отладчика — тоже нет
Я сейчас чаще всего пользуюсь tracepoint'ами и отладочной печатью. GDB тоже неплох.
Sapienti sat!
Re[3]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Grundik2, Вы писали:
G>Здравствуйте, мыщъх, Вы писали:
М>>Здравствуйте, GRIENDERS, Вы писали:
G>и за и против. что в итоге?
занимайтесь всем подряд. ищите то, что у вас получается хорошо. в идеале -- лучше, чем у остальных. развивайте свои сильные стороны и забейте на слабые. возможно, вы восходящая звезда драйверостроения под никсы. возможно, это путь в никуда.
никто не знает, что спрятано внутри вас. писать драйвера -- это не бананами торговать. фундаментальная составляющая в драйверописании исчезающе мала и потому вам придется постоянно переучиваться. а вот если вы глубоко знаете мат. часть, то делать деньги можно на технологиях, пришедших из 50х — 60х годов и все еще востребованных. как раз основной пик CS приходится на середину прошлого века. в 80х — 90х в основном допиливали старое и прорывных открытий по пальцам пересчитать.
в плане миграции -- будьте осторожны с редкими профессиями. потерять работу за рубежом легко, а найти трудно. а по H1B визе вы ограничены во времени на поиск нового работодателя.
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: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, GRIENDERS, Вы писали:
GRI>Работаю c C около года, вернее, он как хобби. Так в основном на ruby и c#. GRI>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
Тоже самое, что и везде. Спецов мало, работы хватает, но не так чтоб это заметно влияло на зарплаты в любую сторону. Драйвера ж тоже разные, USB свисток или TCP/IP требуют разного опыта, за опыт и платят, но и это как везде.
Re[3]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Grundik2, Вы писали:
C>>Вопрос какой-то странный. Специалисты по Линуксу, которые знают его внутреннее устройство и умеют им пользоваться, очень неплохо ценятся (так скажем, тут цифра в 5 человек на форуме прозвучала — я в эти 5 человек вхожу ). Причём именно драйверописательством заниматься совсем необязательно. G>что тогда входит в пользоваться линуксом? чем вы занимаеетесь?
У меня — создание кластерных систем: разный тюниниг (сетевого стека, латентности, пропускной способности), изоляция процессов через cgroup и namespaces и т.д. Драйвера писать не приходилось, а вот дорабатывать файловую систему в ядре пришлось.
Мой личный рекорд — кластер из 10000 узлов на Amazon EC2. Лет 10 назад попал бы в Top10 суперкомпьютеров
G>мне интересно только связка linux + программирование, но не, например, администрирование.
Администрирование тоже полезно. Не в смысле "умение настраивать Оракл", а в понимании как сделать готовую систему.
C>>Но заниматься драйверами "просто так" ради возможного будущего переезда — не очень имеет смысл. Проще примкнуть к какому-нибудь софтовому проекту и туда изменения засылать. G>расскажите как.
Ну к примеру — берёшь Mesa3D и начинаешь туда писать код.
Sapienti sat!
Re: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, GRIENDERS, Вы писали:
GRI>Работаю c C около года, вернее, он как хобби. Так в основном на ruby и c#. GRI>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
Вопрос какой-то странный. Специалисты по Линуксу, которые знают его внутреннее устройство и умеют им пользоваться, очень неплохо ценятся (так скажем, тут цифра в 5 человек на форуме прозвучала — я в эти 5 человек вхожу ). Причём именно драйверописательством заниматься совсем необязательно.
Но заниматься драйверами "просто так" ради возможного будущего переезда — не очень имеет смысл. Проще примкнуть к какому-нибудь софтовому проекту и туда изменения засылать. К примеру, знаю человека из Польши, который уехал работать в Интел на зарплату более $150k после университета сразу — за счёт участия в разработке 3D-драйверов.
Sapienti sat!
Re[3]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, kaa.python, Вы писали:
aik>>не чтоб самсунг был прям вот ууух, но все таки не доширак и сидит себе в юва. KP>А ничего, что Samsung в ВА, а не ЮВА?
блин. это _в_корне_ меняет все дело. да.
Re[7]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, aik, Вы писали:
aik>блин. это _в_корне_ меняет все дело. да.
Сарказм тут не уместен, так как реально в корне меняет и единственным местом в ЮВА где хорошо платят является Сингапур, а там драйвера мало кому вперлись.
Re[5]: Написание драйверов под Linux на С, стоит ли начинать?
M>Как показывает моя практика, читать сорцы это занятие требующее определенных навыков. И достаточно нелюбимое в общей массе, которая предпочитает читать доки.
вы хорошо подумали прежде чем написать это ? ведь внезапно оказывается что наличие внятной доки значительно важнее чем наличие исходников. отсюда следует (барабанная дробь) что open source вобщем-то и "не нужен"
M>Посему скачать какой-нить WDF с примерами для такой же школоты, имхо, куда проще.
вы так говорите будто это что-то плохое. а меж тем kmdf ускоряет разработку некоторых типов драйверов в разы
паранойя не болезнь, а критерий профпригодности
Re[17]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>13354 штук в 3.6.9. R>отлично R>это означает что несколько тысяч раз в коде linux kernel запрещает прерывания, хотя в это время некоторые из них вполне могли бы быть обработаны, если бы использовался механизм irql R>могу еще про giant lock напомнить, удаленный только в 2011 кажется
И тут Остапа понесло
Во-первых, изменение IRQL очень тяжеловесно. Мне известно три различных реализации в разных виндах с разными халами:
1. Запрещение прерываний — перепрограммирование PIC — разрешение части прерываний — Critical Section (CS) — запрещение прерываний — перепрограммирование PIC — разрешение прерываний.
2. Полный барьер памяти — перепрограммирование Task Priority Register в local APIC — полный барьер памяти — CS — полный барьер памяти — перепрограммирование TPR в local APIC — полный барьер памяти.
3. Тупо изменение IRQL в KPCR. Используется lazy-logic, т.е. реальное перепрограммирование APIC происходит только по приходу прерывания (причем если DIRQL меньше нашего — мы должны послать его снова, чтобы не потерять).
Что же мы видим? В п.1 у нас два быстрых cli/sti спинлока, поэтому если критическая секция (CS) невелика, то оверхед будет составлять десятки процентов, а то и сотни. А длинные CS не приветствуются. Второй вариант вводит 4 дополнительных барьера памяти, что очень плохо сказывается на SMP системе (привет масштабированию). Третий вариант хорош, однако даже при небольшой нагрузке по прерываниям происходит деградация как по производительности данного cpu (а чем длиннее CS, тем выше вероятность этого), так и по латенси прерываний с низким DIRQL.
spin_lock_irqsave() же, хоть и увеличивает латенси и снижает производительность, но делает это на заранее известные величины, слабо зависящие от нагрузки и конфигурации системы. К тому же, из этих 13354 штук часть просто не компилируется (разные архитектуры и драйверы), плюс тенденция к fine-grained locking (т.е. к уменьшению размеров CS, giant lock тоже по этой причине выпилили из ядра) приводит к некоторому увеличению их общего количества.
Так что считать нужно не количество, а длину кода между spin_lock_irqsave/restore(), с учетом частоты выполнения. И хорошо бы покурить мануалы на железо, ибо подозреваю, что половые игры с APIC дают некислый performance penalty, возможно, даже больше чем cli/sti.
А теперь самое интересное. Внутри spin_lock_irqsave/restore() мы не тупо сидим, а выполняем CS, которая связана с обработчиком нашего прерывания. Почему она менее приоритетна чем левый обработчик (да и в случае винды непонятно какой)?
Вот простенькая диаграмма Ганта, показывающая, как может увеличиться латенси нашего irq0 в связи с приходом левого irq1:
irq0 irq1
| |
V V
cpu0 ссссссссссIIIIIIIIIIIIIII..........
cpu1 ..ssssssssCCCCCCCCCC...............
<- T ->
cpu0 ссссссссIIIIIIIIIIIIIIIсс..........
cpu1 ..sssssssssssssssssssssssCCCCCCCCCC
<-------- T' -------->
irq0 приходит к cpu1, irq1 приходит к cpu0
с - наша критическая секция на спинлоке в нити (IST)
С - наша критическая секция на спинлоке в обработчике irq0 (ISR)
I - обработка irq1 (ISR)
s - busy wait на спинлоке (ISR)
. - другая полезная работа
Видно, что в первом случае латенси обоих irq ограничена длиной критической секции (T). Во втором же механизм IRQL увеличивает латенси irq0 на сумму всех "влезших" на cpu0 прерываний (T') плюс уменьшает параллелизм (еще один привет масштабируемости) на MIN(длина CS, сумма обработчиков "влезших" irq). Правда, уменьшилась латенси первого "влезшего" irq, но т.к. мы не можем влиять на меппинг irq->DIRQL, это сомнительный профит.
Если же cpu1 первым захватит наш спинлок, то обработчик irq1 сразу же прервет ожидание cpu0 на spin_lock_irqsave(). При включенной преемптивности ядра, разумеется.
Так что все очень неочевидно, и основное достоинство IRQL — стройность и общность данной концепции. Но, увы, не бесплатно.
З.Ы. И да, подобный подход со spin_lock_irqsave() применяется во многих промышленных ОС, в том же QNX Neutrino. Ибо там область применения хочет маленькой латенси и повышенного детерминизма.
Re[6]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
M>>Как показывает моя практика, читать сорцы это занятие требующее определенных навыков. И достаточно нелюбимое в общей массе, которая предпочитает читать доки. R>вы хорошо подумали прежде чем написать это ? ведь внезапно оказывается что наличие внятной доки значительно важнее чем наличие исходников. отсюда следует (барабанная дробь) что open source вобщем-то и "не нужен"
Сравним большую винду и линукс на предмет документации.
Есть MSDN — отличная и подробная штука. Но, из-за проприетарщины, документация делится на 2 части — юзерам и внутреннюю. В публичной мсдн юзерская документация (в данном случае юзеры — это системные программисты дров), которая описывает надмножество над черным ящиком. Если что пошло не так (не говоря уже об ошибках в мсдн) — вам ппц. Т.е. берете в руки диссасемблер и/или отладчик и вперед реверс инжинирить.
В линуксе есть сорцы + гит + некие доки + lkml (или гугл). Таким образом, линуксовый "МСДН" децентрализован и в нем можно копаться на всех уровнях.
Лайфхак: берем тачку мощную (4+ ядра, 16GB+ RAM, SSD (а еще лучше рейд из ссд)), ставим туда ту же MSVS10, скармливаем ей сорцы линукса для навигации, плагин для гита и все. Непонятно что-то — щелкаем по коду, вызываем историю этого файла и/или git blame, где читаем в комментах к коммиту кто и почему какие изменения внес. Частенько со ссылкой на lkml с обсуждением. Подобный навык прививается за неделю-месяц, зато потом реально хочется плеваться на МСДН.
Но для простого "что либо накидать по-быстрому" МСДН лучше подходит, да.
Написание драйверов под Linux на С, стоит ли начинать?
Работаю c C около года, вернее, он как хобби. Так в основном на ruby и c#.
Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
Re[2]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Handie, Вы писали:
H>Вперед в прошлое? C это язык разработанный в 70х и имеющий ограниченную область применимости — высокие нагрузки, системные вещи и драйверы. Области это низкооплачиваемые (возможно кроме первой), недостатка специалистов нет. Вы явно заблуждаетесь что C сейчас очень востребован и хорошо оплачивается.
мне тоже самое говорили про системное программирование и драйвера в 95 году, как показали практика это не правда
судя по тому что я видел по вакансиям в данной области в США зарплаты от 90 до 140 (лично знаю людей на верхней планке зарплаты)
конкуренция с индусами меньше, так что шансы получить h1b выше
Re[3]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, Handie, Вы писали:
H>>Вперед в прошлое? C это язык разработанный в 70х и имеющий ограниченную область применимости — высокие нагрузки, системные вещи и драйверы. Области это низкооплачиваемые (возможно кроме первой), недостатка специалистов нет. Вы явно заблуждаетесь что C сейчас очень востребован и хорошо оплачивается.
S>мне тоже самое говорили про системное программирование и драйвера в 95 году, как показали практика это не правда
S>судя по тому что я видел по вакансиям в данной области в США зарплаты от 90 до 140 (лично знаю людей на верхней планке зарплаты) S>конкуренция с индусами меньше, так что шансы получить h1b выше
140 в сша это немного. а то, что конкуренция меньше, это хорошо.
вернее, тогда я перефразирую вопрос для других: "есть ли потенциал у тех, кто только начинает изучать написание драйверов под Linux и большой ли он? Неважно в какой стране, неважно на c или с++."
Re[4]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Grundik2, Вы писали:
G>140 в сша это немного. а то, что конкуренция меньше, это хорошо.
если 140 это немного на h1b и для 1-2 работы, то сколько тогда хорошая зарплата 170-200 ?
помоему на rsdn таких меньше 5 человек
кого я знаю с зарплатами больше 110 не в NY реальные монстры
Re: Написание драйверов под Linux на С, стоит ли начинать?
под винду стоит
под линукс нет GRI>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
паранойя не болезнь, а критерий профпригодности
Re[2]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>под винду стоит R>под линукс нет GRI>>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
если несекрет почему
вакансий под linux вроде бы больше
Re[4]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>любая школота может посмотреть сорец кернела и сляпать по быстрому всякое глючное, уронив попутно цены до привычного доширачного уровня
То есть качество там, где тайное знание, где поставляемый sdk не все вопросы освещает, где посмотреть на исходники правильно сделанных драйверов проблематично и т.п.?
Re[5]: Написание драйверов под Linux на С, стоит ли начинать?
M>То есть качество там, где тайное знание, где поставляемый sdk не все вопросы освещает, где посмотреть на исходники правильно сделанных драйверов проблематично и т.п.?
я про качество не говорил ничего
вы между строк бросайте читать — у вас плохо выходит
паранойя не болезнь, а критерий профпригодности
Re[4]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
S>>вакансий под linux вроде бы больше R>очевидно именно поэтому R>любая школота может посмотреть сорец кернела и сляпать по быстрому всякое глючное, уронив попутно цены до привычного доширачного уровня
По моему опыту, как раз дошираком питаются системщики, пишущие говнодрайвера на Винде за штукобаксов в месяц.
Sapienti sat!
Re[5]: Написание драйверов под Linux на С, стоит ли начинать?
C>По моему опыту, как раз дошираком питаются системщики, пишущие говнодрайвера на Винде за штукобаксов в месяц.
можешь скинуть координаты парочки хотя бы например ?
паранойя не болезнь, а критерий профпригодности
Re[2]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, GRIENDERS, Вы писали:
GRI>>Работаю c C около года, вернее, он как хобби. Так в основном на ruby и c#. GRI>>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА. C>Вопрос какой-то странный. Специалисты по Линуксу, которые знают его внутреннее устройство и умеют им пользоваться, очень неплохо ценятся (так скажем, тут цифра в 5 человек на форуме прозвучала — я в эти 5 человек вхожу ). Причём именно драйверописательством заниматься совсем необязательно.
что тогда входит в пользоваться линуксом? чем вы занимаеетесь?
мне интересно только связка linux + программирование, но не, например, администрирование.
C>Но заниматься драйверами "просто так" ради возможного будущего переезда — не очень имеет смысл. Проще примкнуть к какому-нибудь софтовому проекту и туда изменения засылать.
расскажите как.
Re[2]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>под винду стоит R>под линукс нет GRI>>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
объясни почему такая уверенность
Re[3]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Grundik2, Вы писали:
GRI>>>Работаю c C около года, вернее, он как хобби. Так в основном на ruby и c#. GRI>>>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА. C>>Вопрос какой-то странный. Специалисты по Линуксу, которые знают его внутреннее устройство и умеют им пользоваться, очень неплохо ценятся (так скажем, тут цифра в 5 человек на форуме прозвучала — я в эти 5 человек вхожу ). Причём именно драйверописательством заниматься совсем необязательно. G>что тогда входит в пользоваться линуксом? чем вы занимаеетесь? G>мне интересно только связка linux + программирование, но не, например, администрирование.
Я не он, но отвечу
Лично я зашел из винды в линукс с embedded систем, сначала микроконтроллеры, потом всякий компактный arm/ppc/mips на кастомных платах — и такой работы в Москве достаточно. Я после такого только на нормальный (ну, серверный) линукс перешел. Как юзер линукса — я никакой, он для меня до сих пор просто здоровенная фирмварь, а не, например, десктопная операционка (хотя рабочий ноут под дебианом). Но и так в Австралию вывезли, так тут плохо с линуксдрайверописателями
C>>Но заниматься драйверами "просто так" ради возможного будущего переезда — не очень имеет смысл. Проще примкнуть к какому-нибудь софтовому проекту и туда изменения засылать. G>расскажите как.
Имхо — ерунда это. Надо не волонтерить, а искать конкретную работу со словом "embedded" и там разбираться по месту. Готовых кернелхакеров маловато, так что есть маза прорваться, если ты _в_принципе_ понимаешь как работают проц, память, шины всякие там на логическом уровне. Ну или прорываться в Parallels, они очень грамотно там с линуксом обращаются и набирают адекватно, как мне показалось.
Re[4]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Grundik2, Вы писали:
G>>>расскажите как. C>>Ну к примеру — берёшь Mesa3D и начинаешь туда писать код. G>Спасибо за наводку. а что еще есть?
Да полно всего. Читаешь LKML и ищешь что тебе больше нравится, а потом туда подключаешься.
Sapienti sat!
Re: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, GRIENDERS, Вы писали:
GRI>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
Драйвера не самый простой и прямой способ переехать; в США, конечно, еще куда ни шло, но зачем в Таиланде или Вьетнаме разработчик драйверов не очень ясно. Самое главное, ты не забывай что спрос на системщиков ниже спроса на прикладников.
Re[2]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, GRIENDERS, Вы писали:
GRI>>Насколько выгодно в долгосрочной перспективе начать изучать написание драйверов под Linux на C? Планы — мигрировать, будь то США в идеале или ЮВА.
KP>Драйвера не самый простой и прямой способ переехать; в США, конечно, еще куда ни шло, но зачем в Таиланде или Вьетнаме разработчик драйверов не очень ясно. Самое главное, ты не забывай что спрос на системщиков ниже спроса на прикладников.
А почему нет? Есть же международные конторы в ЮВА.
Re[4]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, _stun_, Вы писали:
G>>А почему нет? Есть же международные конторы в ЮВА. __>Ну, они там ищут "разработчиков", для которых даже "Доширак" — деликатес. Вы на этом пайке не выживете.
не чтоб самсунг был прям вот ууух, но все таки не доширак и сидит себе в юва.
Re[5]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Grundik2, Вы писали:
G>>>расскажите как. C>>Ну к примеру — берёшь Mesa3D и начинаешь туда писать код. G>Спасибо за наводку. а что еще есть?
линуксоиду _жизненно_ необходимо прокачивать скилл гугления. удобоваримого аналога msdn'а нет и близко, хотя попытки и предпринимаются.
Re[4]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, _stun_, Вы писали:
__>Здравствуйте, Grundik2, Вы писали:
G>>А почему нет? Есть же международные конторы в ЮВА.
__>Ну, они там ищут "разработчиков", для которых даже "Доширак" — деликатес. Вы на этом пайке не выживете.
я живу на 100 руб в день если перевести на рубли.
Re[7]: Написание драйверов под Linux на С, стоит ли начинать?
R>>аналога visual studio — нет KP>Eclipse
это совсем не смешная шутка
KP> На днях запустил VS — ну жесть какое УГ.
2012 как-то да, очень не удачная мордой вышла
KP>Сорцы реально рулят. А WDK нет. Работал и с тем и с тем.
каталог help в wdk рулит значительно сильнее. ну и в msdn еще статьи
R>>да чо там ядерного — обычный gdb больше всего похож на debug.com 80ых годов KP>обычный gdb интегрируется в Eclipse и SlickEdit
wingdb тоже ничо
паранойя не болезнь, а критерий профпригодности
Re[9]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>это совсем не смешная шутка
eclipse + cdt — очень даже не плохая штука. особенно с учетом того, что в нем можно не только на C++, но и на Java и прочих приличных языках писать.
R>2012 как-то да, очень не удачная мордой вышла
Я про 2010, 2012 даже в глаза не видел.
R>каталог help в wdk рулит значительно сильнее. ну и в msdn еще статьи
Похоже, дело во вкусе фламастеров Мне реально удобнее поглядеть на код функции и понять что нужно, плюс никаких "недокументированных" возможностей.
R>wingdb тоже ничо
Мне он тоже очень нравится. Так что в этом я с тобой согласен.
Re[11]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>хм, java и "приличный язык" тут явно не сочетаются
Приличные — кроссплатформенные. Не приличные — Windows only.
R>anyway, он уже научился стартовать быстрее чем за пару минут и жрать хотя бы пару гигов памяти вместо 3-5 ?
Стартует за секунд 30, памяти жрет до гига. Но, надо отметить, у меня 16 гигов памяти и SSD винт, при этом, на работе система куда слабее, но тоже все летает
R>например в коде linux ядра до сих пор нету даже простых аннотаций к прототипам ф-ций — например некую ф-цию не можно дергать на повышенном irql. отсюда проистекают всякие далекоидущие следствия вроде отсутствия статического verifier. да и просто driver verifier в ядре нет R>понятия symbol packages/symbol server отсутствуют как класс. соотв-но дамп, присланный с машины в другом полушарии бесполезен чуть более чем полностью
Я драйверов пишу мало,поэтому именно эта часть меня мало заботит, а наличие исходников, на оборот, критично.
R>и так далее, и тому подобное. так и живут в 80ых годах прошлого века
Везде есть минусы и плюсы
Re[5]: Написание драйверов под Linux на С, стоит ли начинать?
__>>Ну, они там ищут "разработчиков", для которых даже "Доширак" — деликатес. Вы на этом пайке не выживете.
G>я живу на 100 руб в день если перевести на рубли.
И что, и жилье в эту сумму входит? И что, и дальше так и планируете? И т.д. и т.п.
Re[5]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, redp, Вы писали:
S>>>вакансий под linux вроде бы больше R>>очевидно именно поэтому R>>любая школота может посмотреть сорец кернела и сляпать по быстрому всякое глючное, уронив попутно цены до привычного доширачного уровня C>По моему опыту, как раз дошираком питаются системщики, пишущие говнодрайвера на Винде за штукобаксов в месяц.
почему-то еще не встречал ни одного писателя драйверов готовых работать меньше чем за $5k в месяц
Re[5]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Cyberax, Вы писали:
C>По моему опыту, как раз дошираком питаются системщики, пишущие говнодрайвера на Винде за штукобаксов в месяц.
А вообще системное программирование под винду, как оплачивается? Например в сфере разработки всяких антивирусов, систем противодействия утечкам (DLP) и т.п.
Re[6]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, sysenter, Вы писали:
S>А вообще системное программирование под винду, как оплачивается? Например в сфере разработки всяких антивирусов, систем противодействия утечкам (DLP) и т.п.
Ну, собственно, заходите на соседний подфорум с предложениями работодателей, и видите три вакансии от Каспера c суммами... Средняя температура по больнице и видна.
Но работы такой не особо много. Но есть.
Re[11]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
KP>>Похоже, дело во вкусе фламастеров Мне реально удобнее поглядеть на код функции и понять что нужно, плюс никаких "недокументированных" возможностей. R>нет R>например в коде linux ядра до сих пор нету даже простых аннотаций к прототипам ф-ций — например некую ф-цию не можно дергать на повышенном irql.
В Линуксе нет бреда с IRQL. Ближайший аналог — atomic context, вызовы блокирующихся функций оттуда вызовут панику при включенном lockdep (как, в Виндоусе до сих пор нет нормального отладчика блокировок?!).
R>отсюда проистекают всякие далекоидущие следствия вроде отсутствия статического verifier. да и просто driver verifier в ядре нет
Вообще-то, в Линуксе есть полно статических верификаторов. К примеру, для подсистемы RCU (Read-Copy-Update) был написан проект, который нашёл ошибки в куче других параллельных структур.
R>понятия symbol packages/symbol server отсутствуют как класс. соотв-но дамп, присланный с машины в другом полушарии бесполезен чуть более чем полностью R>и так далее, и тому подобное. так и живут в 80ых годах прошлого века
А зачем сервер? У нас уже 100500 лет есть скрипт из 5 строк, который достаёт по ID билда отладочные символы из файлопомойки и исходники из SCM.
Sapienti sat!
Re[12]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Cyberax, Вы писали: R>>например в коде linux ядра до сих пор нету даже простых аннотаций к прототипам ф-ций — например некую ф-цию не можно дергать на повышенном irql. C>В Линуксе нет бреда с IRQL.
очевидно потому что они irql не осилили
по мне так значительно более бредово запрещать вообще все прерывания на spinlock
C> (как, в Виндоусе до сих пор нет нормального отладчика блокировок?!).
опция Deadlock Detection в driver verifier
R>>понятия symbol packages/symbol server отсутствуют как класс. соотв-но дамп, присланный с машины в другом полушарии бесполезен чуть более чем полностью R>>и так далее, и тому подобное. так и живут в 80ых годах прошлого века C>А зачем сервер? У нас уже 100500 лет есть скрипт из 5 строк, который достаёт по ID билда отладочные символы из файлопомойки и исходники из SCM.
это будет работать только если вы не даете пользователю пересобрать ядро самостоятельно (что ай-яй-яй и столлман запретил) или для каждого пересобранного ядра вам нужно иметь symbol info где-нть на вашей стороне
паранойя не болезнь, а критерий профпригодности
Re[8]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, Cyberax, Вы dn — у них в сущности ничего нет C>ROTFL. Вот уж рвотную массу под названием MSDN лучше вообще не вспоминать. Мало того, что там нет нормального поиска (Гугл лучше справляется!), так ещё и полно мест, которые просто недокументированы. Особенно в ядерном программировании.
доказательства будут, или точно такое же неподтвержденное заявление как существование в природе "питающихся дошираком системщиков, пишущих говнодрайвера на Винде за штукобаксов в месяц" ?
R>>аналога visual studio — нет C>Для ядерного программирования он и не особо нужен.
linux не нужен (c) LOR, бгг
R>>wdk — нет. типа сорцов ядра должно быть достаточно, угу-угу три раза C>WDK — это такой непонятный уродец, где даже нет примеров исходников нормальной современной FS или графического драйвера?
я с графическими драйверами дел не имел никогда, но про файловые системы мнение имею. из той кучи, что зачем-то включена в ядро linux, пользоваться можно крайне ограниченным количеством:
— jfs — написана IBM
— xfs — написана Silicon Graphics
— zfs — написана sun
а свое-то у вас есть чо-нть ?
паранойя не болезнь, а критерий профпригодности
Re[9]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>но про файловые системы мнение имею. из той кучи, что зачем-то включена в ядро linux, пользоваться можно крайне ограниченным количеством: R> — zfs — написана sun
Опа, и как давно zfs в ядре Linux?
Ext4 стабилен.
Re[13]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
C>>В Линуксе нет бреда с IRQL. R>очевидно потому что они irql не осилили R>по мне так значительно более бредово запрещать вообще все прерывания на spinlock
Кто нибудь может популярно объяснить можно ли разрешать/запрещать irql на спинлоках и чем чревато?
По мне так это больше архитектурно-религиозное решение т.е. нельзя по этому поводу однозначно утверждать верное это решение или нет.
Re[10]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, redp, Вы писали:
R>>но про файловые системы мнение имею. из той кучи, что зачем-то включена в ядро linux, пользоваться можно крайне ограниченным количеством: R>> — zfs — написана sun
S>Опа, и как давно zfs в ядре Linux? давно
паранойя не болезнь, а критерий профпригодности
Re[14]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, redp, Вы писали:
C>>>В Линуксе нет бреда с IRQL. R>>очевидно потому что они irql не осилили R>>по мне так значительно более бредово запрещать вообще все прерывания на spinlock
S>Кто нибудь может популярно объяснить можно ли разрешать/запрещать irql на спинлоках и чем чревато?
проще ознакомиться с матчастью я думаю
паранойя не болезнь, а критерий профпригодности
Re[11]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>>>но про файловые системы мнение имею. из той кучи, что зачем-то включена в ядро linux, пользоваться можно крайне ограниченным количеством: R>>> — zfs — написана sun S>>Опа, и как давно zfs в ядре Linux? R>давно
Ты выше утверждал, что zfs среди прочих зачем-то включена в ядро.
Повторяю свой вопрос, как давно zfs включена в состав ядра linux?
Re[12]: Написание драйверов под Linux на С, стоит ли начинать?
S>Ты выше утверждал, что zfs среди прочих зачем-то включена в ядро. S>Повторяю свой вопрос, как давно zfs включена в состав ядра linux?
там выше т-щ Cyberax столь же уверенно упоминал о всяких левых проектах, которые в ядро не включены, но должны чо-то кому-то доказать
ящитаю мое доказательство ничуть не хуже — zfs есть и вполне может в ядре использоваться
не ?
паранойя не болезнь, а критерий профпригодности
Re[13]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
R>там выше т-щ Cyberax столь же уверенно упоминал о всяких левых проектах, которые в ядро не включены, но должны чо-то кому-то доказать R>ящитаю мое доказательство ничуть не хуже — zfs есть и вполне может в ядре использоваться R>не ?
Ты выше утверждал, что zfs включена в состав ядра linux, а оказалось что нет. Теперь показываешь пальцем на Cyberax и пытаешься оправдаться.
Не хорошо это, не профессионально))
Re[14]: Написание драйверов под Linux на С, стоит ли начинать?
S>Ты выше утверждал, что zfs включена в состав ядра linux, а оказалось что нет. Теперь показываешь пальцем на Cyberax и пытаешься оправдаться. S>Не хорошо это, не профессионально))
поскольку из трех упомянутых fs только одна не включена в ядро "официально" — будем считать что на треть стыдно
паранойя не болезнь, а критерий профпригодности
Re[16]: Написание драйверов под Linux на С, стоит ли начинать?
V>The balls are the same.
я искренне поражен встретить столь подробный ответ по делу на русскоязычном ресурсе
но все же это не совсем так
линукс запрещает прерывания насовсем (причем local_irq_disable появился ЕМНИП только в ядре 2.6)
в то время как винда позволяет некоторым видам прерываний происходить даже при DISPATCH_LEVEL
как вы и сказали это больше всего влияет на однопроцессорные машины, с ростом числа камней значение этого решения падает (при правильном равномерном распределении прерываний на все доступные камни)
паранойя не болезнь, а критерий профпригодности
Re[17]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
V>>The balls are the same. R>я искренне поражен встретить столь подробный ответ по делу на русскоязычном ресурсе
Это всего лишь вершина айсберга
R>но все же это не совсем так R>линукс запрещает прерывания насовсем (причем local_irq_disable появился ЕМНИП только в ядре 2.6) R>в то время как винда позволяет некоторым видам прерываний происходить даже при DISPATCH_LEVEL R>как вы и сказали это больше всего влияет на однопроцессорные машины, с ростом числа камней значение этого решения падает (при правильном равномерном распределении прерываний на все доступные камни)
Когда линукс запрещает? spin_lock() аппаратные прерывания не запрещает вообще, как и win при DISPATCH_LEVEL — запрещается только решедулинг. А вот при синхронизации с ISR линуксовый spin_lock_irqsave() запрещает все локальные прерывания, когда win просто поднимает уровень до DIRQL и, таким образом, запрещает только часть из них — причем непонятно какую. Вроде я это упомянул
А вот когда приходит аппаратное прерывание, его ISR win вызывает на определенном DIRQL (часть аппаратных прерываний размаскирована). С линуксом сложнее — он эволюционировал с 2.5 примерно так:
1. Текущая линия irq замаскирована на всех процессорах, *все* остальные прерывания размаскированы ("круче" чем в win).
2. При аттаче можно было указать флаг SA_INTERRUPT, при этом на текущем cpu *все* прерывания замаскированы, а вызвавшая прерывание линия irq замаскирована еще и глобально.
3. На lkml было долгое обсуждение, по результатом которого SA_INTERRUPT стал применяться по дефолту (осознанное эволюционное решение, Линус сказал, мол, нехрен писать кривые долгие ISR, поэтому будем запрещать глобально).
4. Поведение SA_INTERRUPT осталось, произошел переход на threaded-модель.
Как то так
Re[6]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, _stun_, Вы писали:
__>Здравствуйте, Grundik2, Вы писали:
__>>>Ну, они там ищут "разработчиков", для которых даже "Доширак" — деликатес. Вы на этом пайке не выживете.
G>>я живу на 100 руб в день если перевести на рубли.
__>И что, и жилье в эту сумму входит? И что, и дальше так и планируете? И т.д. и т.п.
Ну не все ведь брошены на произвол судьбы без квартир, оставленных им в наследство бабушками.
Re[13]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
S>>Ты выше утверждал, что zfs среди прочих зачем-то включена в ядро. S>>Повторяю свой вопрос, как давно zfs включена в состав ядра linux? R>там выше т-щ Cyberax столь же уверенно упоминал о всяких левых проектах, которые в ядро не включены, но должны чо-то кому-то доказать
Можно ссылку где я про это говорил?
R>ящитаю мое доказательство ничуть не хуже — zfs есть и вполне может в ядре использоваться
В mainline её нет, распространять нельзя — она смысла не имеет.
Sapienti sat!
Re[8]: Написание драйверов под Linux на С, стоит ли начинать?
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 сильно отличается от драйвера под видюху. узость специализации усложняет поиски работы, с другой стороны она упрощает миграцию, т.к. своих специалистов найти сложно (в силу узости).
и за и против. что в итоге?
Re[16]: Написание драйверов под Linux на С, стоит ли начинать?
C>Цитирую:
вы меня разве цитируете ?
C>Фэловый стек в Винде писали кретины, и до сих пор не могут его нормально переделать. Я уже как-то об этом писал: http://www.rsdn.ru/forum/flame.comp/3497317.1
Здравствуйте, redp, Вы писали:
R>любая школота может посмотреть сорец кернела и сляпать по быстрому всякое глючное, уронив попутно цены до привычного доширачного уровня
Как показывает моя практика, читать сорцы это занятие требующее определенных навыков. И достаточно нелюбимое в общей массе, которая предпочитает читать доки. Посему скачать какой-нить WDF с примерами для такой же школоты, имхо, куда проще.
Re[13]: Написание драйверов под Linux на С, стоит ли начинать?
On 25.03.2013 08:35, redp wrote: > бгг > почти стабильная файловая система, да
Не знаю что такок btrfs, но термин "почти стабильная файловая система"
отлично описывает состояние дел в NTFS на текущий момент времени.
Из свежего: попытка удаления файла гарантированно не занятого никаким
другим процессом с десктопа. calculating ... чего-то там, и висяк.
5...10 мин — никакого результата (надо удалить ОДИН файл). Перезапуск
эксплорера и винды не помогает, chkdsk уверяет что всё ок, event log-и
чисты. Лицензионный Windows 2008 server(!!!), брендовое железо.
--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re[6]: Написание драйверов под Linux на С, стоит ли начинать?
M>>Как показывает моя практика, читать сорцы это занятие требующее определенных навыков. И достаточно нелюбимое в общей массе, которая предпочитает читать доки. R>вы хорошо подумали прежде чем написать это ? ведь внезапно оказывается что наличие внятной доки значительно важнее чем наличие исходников. отсюда следует (барабанная дробь) что open source вобщем-то и "не нужен"
Да, для решения ряда задач типа "накидать по быстрому" open source в общем-то и не нужен.
M>>Посему скачать какой-нить WDF с примерами для такой же школоты, имхо, куда проще. R>вы так говорите будто это что-то плохое. а меж тем kmdf ускоряет разработку некоторых типов драйверов в разы
Скорее делает разработку объектно-ориентированной. Вместо одной большой функции вы получаете сотню маленьких. Но это дело вкуса. И в моей специфике лично я не вижу, как kmdf может ускорить разработку драйвера хотя бы на 1%
Re[18]: Написание драйверов под Linux на С, стоит ли начинать?
V>Так что все очень неочевидно, и основное достоинство IRQL — стройность и общность данной концепции. Но, увы, не бесплатно.
Про что изначально речь и шла, между прочим. IMHO (и не только M, да и не всегда H) с концептуальной точки зрения под винду писать удобнее, как драйверы, так и весь остальной софт. Да, в том числе благодаря MSDN, удобным IDE и много еще чему.
Но все это "увы, не бесплатно" (С)
PS: мне казалось очевидным, что crowd-sourced OS должна быть заметно сильнее proprietary в плане обсуждаемых механизмов. Просто в силу того, что открытый исходный код дает возможность высказаться сотням и тысячам maintainer'ов по всему миру. Тогда как ядро NT, пусть даже и написанное программистами высочайшего класса, все равно обсуждается ограниченным числом лиц. Плюс к тому, сильно привязано по совместимости с предыдущими версиями. Собственно, это одновременно и самое важное преимущество Windows, и самый же большой ее недостаток (для разработчиков). И так было всегда и везде — сохранение совместимости жрало больше всего.
Re[14]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, hrensgory, Вы писали:
H>Из свежего: попытка удаления файла гарантированно не занятого никаким H>другим процессом с десктопа. calculating ... чего-то там, и висяк. H>5...10 мин — никакого результата (надо удалить ОДИН файл). Перезапуск H>эксплорера и винды не помогает, chkdsk уверяет что всё ок, event log-и H>чисты. Лицензионный Windows 2008 server(!!!), брендовое железо.
Подтверждаю, часто с таким сталкиваюсь.
Ещё есть глюки с внешним винтом, воткнул в комп а вытащить уже не получается, винда пишет что устройство занято. Всё что его использовало закрыто, информация сохранена и не важно сколько времени ждать, можно час а можно два, устройство нельзя отмонтировать.
Re[19]: Написание драйверов под Linux на С, стоит ли начинать?
SD>PS: мне казалось очевидным, что crowd-sourced OS должна быть заметно сильнее proprietary в плане обсуждаемых механизмов. Просто в силу того, что открытый исходный код дает возможность высказаться сотням и тысячам maintainer'ов по всему миру.
не менее очевидно что со временем это должно приводить к адовой фрагментации. поскольку linux пытается объять необъятное — от встраиваемых однокристалок до серверов с сотнями камней, то разные люди пишут патчи для своих радикально разных задач
в результате мы имеем кучу "неофициальных" веток и патчей с разным функционалом, разного качества и при этом плохо протестированных на совместимость друг с другом. и этот зоопарк еще более усугубляется религиозным маразмом как с тем же zfs
паранойя не болезнь, а критерий профпригодности
Re[18]: Написание драйверов под Linux на С, стоит ли начинать?
V>И тут Остапа понесло
извините
V>А теперь самое интересное. Внутри spin_lock_irqsave/restore() мы не тупо сидим, а выполняем CS, которая связана с обработчиком нашего прерывания. Почему она менее приоритетна чем левый обработчик (да и в случае винды непонятно какой)?
в винде обычно DISPATCH_LEVEL используется для атомарной модификации глобальных структур данных. при этом вероятность того что прерывание от устройства будет использовать их же — очень мала. соотв-но винда считает что прерывания от устройств имеют более высокий приоритет и их нужно обрабатывать cразу во время их возникновения
V>Вот простенькая диаграмма Ганта
диаграмма верна только для случая, когда cpu1 тупо крутится на локе. а если ему в этот момент приходит прерывание ?
паранойя не болезнь, а критерий профпригодности
Re[19]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
V>>И тут Остапа понесло R>извините
Я хотел сказать, что понесло *меня* писать такой объемный пост
И что-то тормоза не работают...
V>>А теперь самое интересное. Внутри spin_lock_irqsave/restore() мы не тупо сидим, а выполняем CS, которая связана с обработчиком нашего прерывания. Почему она менее приоритетна чем левый обработчик (да и в случае винды непонятно какой)? R>в винде обычно DISPATCH_LEVEL используется для атомарной модификации глобальных структур данных. при этом вероятность того что прерывание от устройства будет использовать их же — очень мала. соотв-но винда считает что прерывания от устройств имеют более высокий приоритет и их нужно обрабатывать cразу во время их возникновения
Цимес в том, что CS неочевидным образом связана с обработчиком прерывания на другом cpu, поэтому выигрыша в целом нет.
Для модификации структур данных используется не только DISPATCH_LEVEL, нередко идет переход на SYNCH_LEVEL — это раз. Два — смотрите реализацию KfRaiseIrql; даже если мы повышаем уровень с PASSIVE_LEVEL до APC_LEVEL, идет либо cli/sti + перепрограммирование PIC, либо барьеры + APIC. Это чудовищный оверхед по сравнению с тем же линуксом, где в таких случаях используется spin_lock() (а не *_irqsave()-версия).
Чтобы не быть голословным, вот реализация из первого варианта (во всех виндах XP+ с PIC):
.text:80012940 ; Exported entry 18. KfRaiseIrql
.text:80012940
.text:80012940 ; __fastcall KfRaiseIrql(x)
.text:80012940 public @KfRaiseIrql@4
.text:80012940 @KfRaiseIrql@4 proc near ; CODE XREF: KeAcquireSpinLockRaiseToSynch(x)+6p
.text:80012940 ; KeAcquireInStackQueuedSpinLock(x,x)+Dp ...
.text:80012940 mov eax, large fs:24h
.text:80012946 movzx ecx, cl
.text:80012949 cmp ecx, 2
.text:8001294C jbe short loc_80012974
.text:8001294E mov edx, eax
.text:80012950 pushf
.text:80012951 cli
.text:80012952 mov large fs:24h, cl
.text:80012959 mov eax, ds:KiI8259MaskTable[ecx*4]
.text:80012960 or eax, large fs:30h
.text:80012967 out 21h, al ; Interrupt controller, 8259A.
.text:80012969 shr eax, 8
.text:8001296C out 0A1h, al ; Interrupt Controller #2, 8259A
.text:8001296E popf
.text:8001296F mov eax, edx
.text:80012971 retn
KfLowerIrql примерно такой же. Чувствуете???
Вариант с APIC есть в WRK в исходных кодах.
В семерке допилили APIC-версию KfRaiseIrql до нормального уровня, но опять же, однозначно сказать что лучше нельзя — it depends. Выясняется это только статистически, наргрузочным тестированием по разным методикам с разными сценариями загрузки. И по косвенным данным винда проигрывает линуксу по масштабируемости и умению держать irq-storm (хотя винда есть в топ-500, но там явно заточенная версия, даже не серверная; интересно было бы глянуть).
V>>Вот простенькая диаграмма Ганта R>диаграмма верна только для случая, когда cpu1 тупо крутится на локе. а если ему в этот момент приходит прерывание ?
Я просто показал вариант, когда IRQL-концепция проигрывает. Если ввести irq3 то "масшатбируемость" сравняется, а вот детерминизм латенси — нет (не в пользу винды). В принципе, я могу придумать сценарий, когда IRQL рулит по всем параметрам, но как часто он будет происходить? И почему бы не ввести irq4 и не вернуться к исходной диаграмме? Причем интуитивно понятно, вероятность прихода 4-х разных irq на одном временном отрезке ниже, чем приход трех, и еще ниже чем двух, и, тем более, одного (собственно, на что программисты винды и рассчитывают).
Так что пока нет на руках тестов по правильным методикам, следует избегать безапелляционных заявлений, имхо
Re[19]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, SkyDance, Вы писали:
V>>Так что все очень неочевидно, и основное достоинство IRQL — стройность и общность данной концепции. Но, увы, не бесплатно.
SD> SD>Про что изначально речь и шла, между прочим. IMHO (и не только M, да и не всегда H) с концептуальной точки зрения под винду писать удобнее, как драйверы, так и весь остальной софт. Да, в том числе благодаря MSDN, удобным IDE и много еще чему. SD>Но все это "увы, не бесплатно" (С)
Я среагировал на дискуссию "бред IRQL" vs "линукс не дорос до IRQL".
А с концептуальной т.з. может и под винду удобнее писать, но с практической все наоборот. Во-первых, у них оверинжиниринг (следствие стабильности модели). Тупо постройте стейт машину драйвера в большой винде и линуксе — удивитесь. Под винду сложнее на порядки писать драйвера, ибо там и событий больше, и состояний. Плюс, драйверные фреймворки там точно проектировали индусы (сужу по своему опыту разработки дров под аппаратное кодирование с помощью DXVA, DXVA2 и v4l2; ах DXVA не кодирует, а DXVA2 пашет только с висты — лол).
Документация — отдельная тема.
Re[20]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
SD>>PS: мне казалось очевидным, что crowd-sourced OS должна быть заметно сильнее proprietary в плане обсуждаемых механизмов. Просто в силу того, что открытый исходный код дает возможность высказаться сотням и тысячам maintainer'ов по всему миру. R>не менее очевидно что со временем это должно приводить к адовой фрагментации. поскольку linux пытается объять необъятное — от встраиваемых однокристалок до серверов с сотнями камней, то разные люди пишут патчи для своих радикально разных задач
По факту этого не произошло. Получилось наоборот — Линукс стал настолько гибким, что легко подходит для самых разных задач.
R>в результате мы имеем кучу "неофициальных" веток и патчей с разным функционалом, разного качества и при этом плохо протестированных на совместимость друг с другом. и этот зоопарк еще более усугубляется религиозным маразмом как с тем же zfs
Неофициальных веток, в которых меняется core-функционал нет (разве что ветка Kon Kolivas'а, в которой он поменял планировщик).
Sapienti sat!
Re[7]: Написание драйверов под Linux на С, стоит ли начинать?
В дополнение: тут уже говорили про отсутсвие многих примеров в WDK. Причем, даже некоторые имеющиеся примеры кривые (если брать правильную обработку PnP, WMI сообщений и т.п.), у Волтера Они тоже примеры кривые, а это очень негативно влияет на разработку средних и сложных дров. Пища на любителя, скажу прямо
Re[8]: Написание драйверов под Linux на С, стоит ли начинать?
V>даже некоторые имеющиеся примеры кривые (если брать правильную обработку PnP, WMI сообщений и т.п.), у Волтера Они тоже примеры кривые, а это очень негативно влияет на разработку средних и сложных дров.
к сожалению это чистая правда
я лично очень котирую книжку "Writing Windows Wdm Device Drivers" by Chris Cant
pnp по крайней мере там более-менее близко к правде описан
паранойя не болезнь, а критерий профпригодности
Re[20]: Написание драйверов под Linux на С, стоит ли начинать?
R>не менее очевидно что со временем это должно приводить к адовой фрагментации. поскольку linux пытается объять необъятное — от встраиваемых однокристалок до серверов с сотнями камней, то разные люди пишут патчи для своих радикально разных задач R>в результате мы имеем кучу "неофициальных" веток и патчей с разным функционалом, разного качества и при этом плохо протестированных на совместимость друг с другом. и этот зоопарк еще более усугубляется религиозным маразмом как с тем же zfs
Так и есть.
С точки зрения программистов это даже плюс, требуется больше программистов и за бОльшие деньги
Re[9]: Написание драйверов под Linux на С, стоит ли начинать?
Здравствуйте, redp, Вы писали:
V>>даже некоторые имеющиеся примеры кривые (если брать правильную обработку PnP, WMI сообщений и т.п.), у Волтера Они тоже примеры кривые, а это очень негативно влияет на разработку средних и сложных дров. R>к сожалению это чистая правда R>я лично очень котирую книжку "Writing Windows Wdm Device Drivers" by Chris Cant R>pnp по крайней мере там более-менее близко к правде описан
Мда... И сколько за весь этот секс (написание драйверов) с виндой платят?
Сдаётся мне, что проще и по деньгам не меньше, как минимум это тупо писать на C#/Java или прикладное ПО на C++.
Re[10]: Написание драйверов под Linux на С, стоит ли начинать?
