AVK>Вот что я точно заметил, так это то, что человек, который пытался писать драйвера с очень большой долей вероятности через некоторое время начинает считать, что круче него только горы.
AVK>И такое, уж поверь, я встречаю на rsdn не первый раз.
Я легко могу накидать ссылок на rsdn, где прикладные программисты вдруг (с чего бы это им?) начинают рассуждать о системных вещах и нести откровенную чушь, например, о шине PCI. Зачем они это делают? В надежде, что никто не заметит, и они типа за умного сойдут

AS>>Ошибки в драйвере стоят в сотни раз больше, чем в юзер-приложении, вы это должны понимать.
AVK>Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?
Смотря какой драйвер. Смотря какая система.
Не следует сравнивать стоимость ошибки в драйвере, управляющем какой-либо железкой в космической технике, со стоимостью ошибки в небольшой биллинговой системе, крутящейся в локальной сетке нескольких домов маленького района.
И наоборот, соответственно.

Здравствуйте, pavel_turbin, Вы писали:

_>- лучше писать на голом С, т.к. тогда можно сделать код "paged".

Поясни?
Чем голый C лучше "одетого"?
Если точнее, то я н еопнял два момента.
1) "голый" -- это не плюсы или без библиотек?
2) что такое сделать код "paged"? Что-то типа оверлеев?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, pavel_turbin, Вы писали:

_>>- лучше писать на голом С, т.к. тогда можно сделать код "paged".

E>Поясни?
E>Чем голый C лучше "одетого"?
E>Если точнее, то я н еопнял два момента.
E>1) "голый" -- это не плюсы или без библиотек?
E>2) что такое сделать код "paged"? Что-то типа оверлеев?


есть такая "прагма"
#pragma alloc_text(PAGE, <function>)

У нее есть один большой недостаток
"The alloc_text pragma does not handle C++ member functions or overloaded functions."
т.е. для класса ее не определишь, ей extern "C" подавай.

можно почитать
здесь

E>2) что такое сделать код "paged"? Что-то типа оверлеев?
есть 2 типа памяти в kernel: paged и non-paged. paged -- Дешево, non-paged -- дорого, т.к. это обычная физическая. paged — виртуальная память и управляется memory manager-ом. non-paged память может быть accessed в любой момент, а paged только в Passive IRQL (такой уродский метод синхронизации в kernel когда блокируешь процессор для всех thread кроме своего).

Код драйвера по умолчанию находится в non-paged. Если вы знаете, что ваш код всегда passive (для очень могих случаев это справедливо), то нет смысла делать его non-paged, т.к. пустая трата ресурса. В этом случае надо объявить функции как "alloc_text(PAGE)" и писать их на "C", без плюсов. Что, естественно, напрягает.

Переход из Passive IRQ в другой может быть сделан неявно, но обычно это документировано.

для функций kernel API указывают уровень

Callers of <function> must be running at IRQL PASSIVE_LEVEL.

здесь

в kernel очень много таких мелких ограничений, но сложного ничего нет. Правда, эти ограничения раздражают порой.

Здравствуйте, ggg, Вы писали:

AVK>>И такое, уж поверь, я встречаю на rsdn не первый раз.
ggg>Я легко могу накидать ссылок на rsdn, где прикладные программисты вдруг (с чего бы это им?) начинают рассуждать о системных вещах и нести откровенную чушь, например, о шине PCI. Зачем они это делают? В надежде, что никто не заметит, и они типа за умного сойдут

Я сам таких могу накидать. Только вот речь немножко о другом — о том, что почему то я регулярно вижу топики, в которых очередной "профессионал" драйверостроения начинает доказывать насколько он крут и насколько все остальные лохи. От прикладников такое если и бывает слышно, то значительно реже.

AVK>>Не, непонимаю. Вот, к примеру, во что обойдется ошибка в коде сервера приложений, работающего в режиме 24х7 можно представить. А драйвера?
ggg>Смотря какой драйвер. Смотря какая система.
ggg>Не следует сравнивать стоимость ошибки в драйвере, управляющем какой-либо железкой в космической технике, со стоимостью ошибки в небольшой биллинговой системе, крутящейся в локальной сетке нескольких домов маленького района.
ggg>И наоборот, соответственно.

Вот. Об этом я и хотел сказать. Высокая стоимость ошибки совсем не означает неимоверной крутости программистов. Возьмем те же сервера приложений. Там вроде как код самого сервера требует на порядок более высокой (в программистком плане) квалификации. Тем не менее цена ошибки в его ядре скорее всего меньше, нежели цена ошибки в прикладном коде. Подому что ошибка в ядре скорее всего приведет просто к краху сервера, который будет достаточно перезагрузить. В худшем случае придется накатить бекап. А вот ошибки в рассчетах могут вылезти через полгода, когда уже поздно пить боржоми.
Вывод из этого простой — если велика цена ошибки надо прежде всего не программистов наикрутейших искать, а тестировать тщательнее.

Здравствуйте, Дарней, Вы писали:

Д>
Д>вероятно, на самом деле это должно означать "ни один из них не стоит серьезного упоминания"
Д>если не хочешь выглядеть пустозвоном, приведи линк хотя бы на один серьезный продукт, который применяется в настоящее время. Ну и описание своей роли в нем, конечно.

Особенно хотелось бы услышать про применение фильтров ФС.

Здравствуйте, pavel_turbin, Вы писали:

_>есть такая "прагма"
_>#pragma alloc_text(PAGE, <function>)

_>У нее есть один большой недостаток
_>"The alloc_text pragma does not handle C++ member functions or overloaded functions."
_>т.е. для класса ее не определишь, ей extern "C" подавай.

_>можно почитать
_>здесь

Спасибо за разъясниения.
А если попробовать в качестве <function> использовать декорированное имя?
Вторая идея более прикольная. Можно попробовать ещё и такую безумную схему:
1) слинковать всё в либу с pure C интерфейсом
2) Перелинкоать эту либу, с def-файлом, в котором все c++ входы переназначаются в какие-то pure-C имена
3) Понаписать для этих имён прагм.

Правда тогда при отладке без поллитра точно ничего не поймёшь

Кстати, ещё и такой момент, что в C++ коде много невных вызовов rt, но скорее всего это тоже обходится, если вышеперечислю трюки помогают

Но, насколько я понимаю, есть неявные вызовы и в C.
Например функция

void process(void)
{
    int array[4096] = { 0, 0 };
    process_data( array );
};

неявно позовёт memset
и даже

void process(void)
{
    int array[4096];
    get_data( array );
    process_data( array );
};

вызовет в начале себя код в rt, который обратится к каждой странице стекового фрейма.

Как решают такие проблемы? Или волшебная прагма всё побеждает сама?

_>в kernel очень много таких мелких ограничений, но сложного ничего нет. Правда, эти ограничения раздражают порой.

Понятно. Мне тоже кажется, что вынужденное уменее писать на pure-C свидетельствует скорее не о мегаквалификации, а упорстве и трудолюбии, что тем не менее тоже заслуживает уважения

Здравствуйте, Erop, Вы писали:

спасибо за советы. Я думаю, что-то можно придумать, хотя проще забить page/not page и делать все на c++. Неоптимально, но работает

E>Здравствуйте, pavel_turbin, Вы писали:
E>Но, насколько я понимаю, есть неявные вызовы и в C.
E>Например функция
E>

E>void process(void)
E>{
E>    int array[4096] = { 0, 0 };
E>    process_data( array );
E>};
E>

E>вызовет в начале себя код в rt, который обратится к каждой странице стекового фрейма.

стек ограничен 12 Kb. Если вы напишете такую конструкцию ("int array[4096]") в kernel, то очень большой риск поиметь BSOD. Хуже того, crash может и не случится пока не появится 3-ий драйвер, который работает вашем стеке, например какой-нибудь filter. Т.о. в отладке на чистой системе все работает, но иногда падает у клиентов. Вот гадость.

Для отловли таких блох нужно юзать Prefast, он измеряет стак.

Здравствуйте, pavel_turbin, Вы писали:


_>стек ограничен 12 Kb. Если вы напишете такую конструкцию ("int array[4096]") в kernel, то очень большой риск поиметь BSOD. Хуже того, crash может и не случится пока не появится 3-ий драйвер, который работает вашем стеке, например какой-нибудь filter. Т.о. в отладке на чистой системе все работает, но иногда падает у клиентов. Вот гадость.

_>Для отловли таких блох нужно юзать Prefast, он измеряет стак.

А других таких неявных вызовов rt не бывает что ли?

Здравствуйте, Erop, Вы писали:


_>>Для отловли таких блох нужно юзать Prefast, он измеряет стак.

E>А других таких неявных вызовов rt не бывает что ли?

теоритически недолжно быть. На стеке объекты не создают. Вообще в kernel-e поменьше всего нужно использовать никогда не знаешь как это аукнится.

Здравствуйте, Awaken, Вы писали:


AS>>Тоже, открыли Америку. Вот как раз в непрактических науках ничего необычного нет. Попробовать бы заставить сию даму хоть что-ить закодировать настолько низкоуровневое

A>а почему вы думаете что низкоуровневое программирование это высший пилотаж?
A>все драйверщики так думают.
A>по моему спроектировать распределенную ОО-систему, скажем для управления тех.процессом на предпрятии, намного сложнее.

Низкоуровневое программирование (не только) — высший пилотаж, потому что для того, чтобы им овладеть, нужно не читать кучу однообразных книг, чтоб повторить то, что другие делали много раз, а самому заниматься исследованиями

AVK> в которых очередной "профессионал" драйверостроения начинает доказывать насколько он крут и насколько все остальные лохи. От прикладников такое если и бывает слышно, то значительно реже.
Но ведь дыма без огня не бывает, так? Вот некоторые наблюдения.
1) В большинстве случаев в компаниях, специализирующихся на системном программировании, больше порядка, чем в каких-нибудь прикладных ERP, игроделанье или вебе.
Можно внедрить (за откат?) полуглючную ERP-систему, худо бедно она будет работать (ну наймут побольше персонала в крайнем случае). Деньги получены. Все.
Можно по-быстрому написать дешевую игрушку (для гопников?), которую "пипл схавает" (если в ней будет, к примеру, много голых девок и музыка группы Ленинград). Деньги заработаны, прибыль получена. Все.
А вот с системным программированием так не прокатит — ни разу не слышал о понятиях "драйвер-трэшак", "драйвер для быдла", "откат за внедрение драйвера".
Лохами я никого не обзываю, просто системные вещи — это _другая_ _область_, где все по определению более грамотно должно быть, иначе совсем ничего не выйдет.


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

3) "Цена вхождения" в системное программирование выше. Человеку с хорошим базовым (лишь базовым) уровнем программирования потребуется гораздо больше времени на разбор DDK и написание хоть как-то работающего драйвера, чем на изучение J2EE, например, и написание хоть как-то работающего приложения.

Здравствуйте, ggg, Вы писали:

AVK>> в которых очередной "профессионал" драйверостроения начинает доказывать насколько он крут и насколько все остальные лохи. От прикладников такое если и бывает слышно, то значительно реже.
ggg>Но ведь дыма без огня не бывает, так? Вот некоторые наблюдения.
ggg>1) В большинстве случаев в компаниях, специализирующихся на системном программировании, больше порядка, чем в каких-нибудь прикладных ERP, игроделанье или вебе.

Факты в студию. Я такой зависимости не наблюдал.

ggg>Лохами я никого не обзываю, просто системные вещи — это _другая_ _область_, где все по определению более грамотно должно быть,

Определение в студию.

ggg>2) Есть немало "прикладных программистов", которые лишь книжки прочитали, а лично мало что серьезного делали (ну где-то поучаствовали, что-то "порефакторили", где-то поковырялись). Но такие отрывочно-книжные знания вполне прокатывают, подобные люди часто спокойно работают в прикладных областях. В случае с "драйверами" одним чтением книжек и "рефакторингом чужого кода" не обойтись.

Обойтись. Неоднократно наблюдал, когда люди просто правили примеры из DDK под собственные нужды. Большого ума для этого не надо. И вобще, это не аргумент — точно так же нахрапом нельзя ни сервер приложений написать, ни пакет расширения к VS, ни еще кучу других вещей.

ggg>3) "Цена вхождения" в системное программирование выше.

А цена вхождения в проектирование больших приложений еще выше. Ну и что? Это не мешает студентам участвовать и в проектах драйверов, и в проектах серверов приложений.

ggg> Человеку с хорошим базовым (лишь базовым) уровнем программирования потребуется гораздо больше времени на разбор DDK и написание хоть как-то работающего драйвера, чем на изучение J2EE, например

Очень сомнительное утверждение, без каких либо доказательств.

N>Низкоуровневое программирование (не только) — высший пилотаж, потому что для того, чтобы им овладеть, нужно не читать кучу >однообразных книг, чтоб повторить то, что другие делали много раз, а самому заниматься исследованиями

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Очень сомнительное утверждение, без каких либо доказательств.
Самое смешное, что косяки в драйверах вовсе не так редки, как об этом хотят думать некоторые. Иначе чем объяснить основную отмазку производителей железа "скачайте последние драйвера". Или косяки в драйверах S3 от того, что драйвера писать — это вышшый пилотаж, а косяки в ERP — от того, что программеры тупые?

Здравствуйте, Awaken, Вы писали:

N>>Низкоуровневое программирование (не только) — высший пилотаж, потому что для того, чтобы им овладеть, нужно не читать кучу >однообразных книг, чтоб повторить то, что другие делали много раз, а самому заниматься исследованиями

A>так это во многих областях так.
A>взять например поисковую машину для веб. какая "однообразная книга" даст ответ как написать систему поиска,
A>возвращающая нужный результат с первого раза а не кучу левых ссылок?


Это одно из того, что относится к "не только"

Здравствуйте, Noobi, Вы писали:

N>Это одно из того, что относится к "не только"

Поработав в разных областях и в том, числе пописав в свое время драйвера, пришел к выводу, что "не только" относится похоже ко всему. Заморочки/Исследования/Недокументированные фишки есть везде, различаются только ключевые слова, которые вводишь в поиске по гугль-группам и типы проблем от которых голова болит. А вообще, я уже давно мечтаю писать софт без всех этих приключений, что бы р-раз! и все, как по маслу! ан нет, что-то прогресса не видать, все равно приходится мозг напрягать, хоть на дотнете, хоть на С++, хоть на ассемблере.

AVK>Факты в студию. Я такой зависимости не наблюдал.
Вот примеры "трэшовых"(рассказ самих разработчиков) и "откатных" ("черные внедрения") проектов из прикладных областей.
Обратите внимание, речь идет о крупных серьезных компаниях.
Подобных вещей в компаниях, специализирующихся именно на системном программировании, не наблюдал. Я не говорю о случаях, когда кому-то понадобилось на коленке подправить драйвер для доступа к порту какому-нить.

AVK>Обойтись. Неоднократно наблюдал, когда люди просто правили примеры из DDK под собственные нужды. Большого ума для этого не надо.
Я еще раз говорю — речь о компаниях, специализирующихся именно на системном программировании (RTSoft, auriga, SWD (swd.ru)). Там примеры из DDK под собственные нужды не правят.

AVK>точно так же нахрапом нельзя ни сервер приложений написать, ни пакет расширения к VS, ни еще кучу других вещей.
Недавно на rsdn была ссылка на тему "в биллинге от CBOSS не используются внешние ключи и что-то там еще". Т.е. получается, можно написать немалую биллинговую систему (и она вполне себе работала!), игнорируя теорию и принципы СУБД.
Написать серьезный драйвер, игнорируя основные принципы, невозможно.


ggg>>3) "Цена вхождения" в системное программирование выше.
AVK>А цена вхождения в проектирование больших приложений еще выше.
А я говорю именно о программировании.
В проектирование без серьезного опыта программирования я бы никого не допускал.
Раз уж сказали про проектирование: прикладная область допускает существование "кодеров" (или программистов, кодирующих по ТЗ, которое им кто-то составил). В драйверах часто это не так — толпы кодеров с начальными знаниями вы там не найдете.

AVK>Ну и что? Это не мешает студентам участвовать и в проектах драйверов, и в проектах серверов приложений.
Очень разные это студенты.
Те студенты, которые участвуют в проектах драйверов, имеют очень хорошие знания в системном программировании, ядрах, драйверах и т.д. И работают такие студенты (по сути разницы между студентом и специалистом нет) самостоятельно.
В проекты типа серверов приложений часто берут студентов на начальный уровень, писать код под руководством кого-либо более опытного.

AVK>Очень сомнительное утверждение, без каких либо доказательств.
Сугубо мое личное наблюдение, каким был переход людей из прикладной области в низкоуровневую (именно до уровня самостоятельной разработки, а не правки стандартного примера).

Здравствуйте, ggg, Вы писали:

AVK>>Факты в студию. Я такой зависимости не наблюдал.
ggg>Вот примеры "трэшовых"(рассказ самих разработчиков) и "откатных" ("черные внедрения") проектов из прикладных областей.
ggg>Обратите внимание, речь идет о крупных серьезных компаниях.

Это ничего не доказывает. Я могу привести обратных примеров массу. Например Microsoft.

ggg>Подобных вещей в компаниях, специализирующихся именно на системном программировании, не наблюдал.

А что такое "системное программирование"?

ggg> Я не говорю о случаях, когда кому-то понадобилось на коленке подправить драйвер для доступа к порту какому-нить.

А чего так? Чем драйвера на коленке отличаются от прикладного софта на коленке? Халтура, она везде халтура, вне зависимости от конкретной области.

AVK>>Обойтись. Неоднократно наблюдал, когда люди просто правили примеры из DDK под собственные нужды. Большого ума для этого не надо.
ggg>Я еще раз говорю — речь о компаниях, специализирующихся именно на системном программировании (RTSoft, auriga, SWD (swd.ru)). Там примеры из DDK под собственные нужды не правят.

Ну так тогда и бери в качестве сравнения компании, профессионально занимающиеся разработкой софта — Microsoft, Sun etc. А то здорово получается — сравнивать конторы в соседней подворотне с ведущими компаниями страны. Так можно много чего доказать.

AVK>>точно так же нахрапом нельзя ни сервер приложений написать, ни пакет расширения к VS, ни еще кучу других вещей.
ggg>Недавно на rsdn была ссылка на тему "в биллинге от CBOSS не используются внешние ключи и что-то там еще". Т.е. получается, можно написать немалую биллинговую систему (и она вполне себе работала!), игнорируя теорию и принципы СУБД.

Ну и что? Иногда это оправдано.

ggg>Написать серьезный драйвер, игнорируя основные принципы, невозможно.

Драйверы, они всегда игнорируют основные принципы архитектуры ПО ввиду сильных технических ограничений. Так что на эту тему я бы не заикался.

AVK>>А цена вхождения в проектирование больших приложений еще выше.
ggg>А я говорю именно о программировании.

Да чего то незаметно. То какие то истории про внедренцев приводишь, то рассказываешь про архитектурные косяки биллинга от CBOSS. Ты уж определись.

ggg>В проектирование без серьезного опыта программирования я бы никого не допускал.

А любой нормальный программист обязан быть проектировщиком. Ну, разве что, за исключением тех, кто драйвера пишет

ggg>Раз уж сказали про проектирование: прикладная область допускает существование "кодеров" (или программистов, кодирующих по ТЗ, которое им кто-то составил). В драйверах часто это не так — толпы кодеров с начальными знаниями вы там не найдете.

Да есть там все. Сам лично наблюдал.

AVK>>Ну и что? Это не мешает студентам участвовать и в проектах драйверов, и в проектах серверов приложений.
ggg>Очень разные это студенты.
ggg>Те студенты, которые участвуют в проектах драйверов, имеют очень хорошие знания в системном программировании, ядрах, драйверах и т.д. И работают такие студенты (по сути разницы между студентом и специалистом нет) самостоятельно.
ggg>В проекты типа серверов приложений часто берут студентов на начальный уровень, писать код под руководством кого-либо более опытного.

Ну то есть опять выводы без фактов. А вот в одном из проектов, в котором я участвовал во время учебы, студенты писали и драйвера и прикладной код, и никакой разницы в квалификации я не припоминаю, ни до, ни после. Я лично забыл дурацкую возню с ядром как страшный сон.

AVK>>Очень сомнительное утверждение, без каких либо доказательств.
ggg>Сугубо мое личное наблюдение, каким был переход людей из прикладной области в низкоуровневую (именно до уровня самостоятельной разработки, а не правки стандартного примера).

Вот меня и удивляет, что регулярно я слышу такие личные наблюдения исключительно от драйверописателей.

AVK>Ну так тогда и бери в качестве сравнения компании, профессионально занимающиеся разработкой софта — Microsoft, Sun etc.
А с Microsoft и Sun надо бы сравнить QNX, а не swd.ru


AVK>А то здорово получается — сравнивать конторы в соседней подворотне с ведущими компаниями страны. Так можно много чего доказать.
Где это я говорил о "подворотне", или по твоему CBoss и крупнейшие внедренцы ERP в России — это "конторы в соседней подворотне"?

AVK>с ведущими компаниями страны.
А профессиональной разработкой драйверов и не будут в "подворотнях" заниматься.

AVK>То какие то истории про внедренцев приводишь, то рассказываешь про архитектурные косяки биллинга от CBOSS.
Ты сам просил факты о том, что в прикладной области больше мусорных и трешовых проектов (даже в крупных компаниях) — я их привел. Подобных проектов от крупных компаний, разрабатывающих системный софт, я не знаю.


ggg>>Написать серьезный драйвер, игнорируя основные принципы, невозможно.
AVK>Драйверы, они всегда игнорируют основные принципы архитектуры ПО ввиду сильных технических ограничений. Так что на эту тему я бы не заикался.
"Основные принципы архитекутры ПО" неконкретно, можно многое тут наговорить. А конкретные принципы работы ядра — совсем другое дело.


ggg>>Раз уж сказали про проектирование: прикладная область допускает существование "кодеров" (или программистов, кодирующих по ТЗ, которое им кто-то составил). В драйверах часто это не так — толпы кодеров с начальными знаниями вы там не найдете.
AVK>Да есть там все. Сам лично наблюдал.
Это те студенты, которые примеры из ДДК под свои нужны правили? В "конторе в соседней подворотне"?



AVK> Вот меня и удивляет, что регулярно я слышу такие личные наблюдения исключительно от драйверописателей.
А меня удивляет, что, например, в этом треде много людей, "пробовавших и писавших успешные драйверы", перешли вдруг в прикладную область. При этом утверждая, что "драйверы — это ничего особенно". Зарплаты программистов-драйверистов повыше будут (примеры компаний я приводил). Что ж вы побросали-то "возню с ядром"?

Здравствуйте, ggg, Вы писали:

ggg>А вот с системным программированием так не прокатит — ни разу не слышал о понятиях "драйвер-трэшак", "драйвер для быдла", "откат за внедрение драйвера".


Ты это расскажи, например, авторам драйверов к тайваньским сканерам. Наверное они загордятся безпредельно


ggg>Лохами я никого не обзываю, просто системные вещи — это _другая_ _область_, где все по определению более грамотно должно быть, иначе совсем ничего не выйдет.

И это тоже тем же авторам


ggg>3) "Цена вхождения" в системное программирование выше. Человеку с хорошим базовым (лишь базовым) уровнем программирования потребуется гораздо больше времени на разбор DDK и написание хоть как-то работающего драйвера, чем на изучение J2EE, например, и написание хоть как-то работающего приложения.

Ну как-то работающего может быть, а вот хорошее приложенпие спроектировать и реализовать -- это вот хренушки. Это тоже надо уметь.
А вообще снобство ещё никого не красило.
Я ещё раз повторю мнение, что в системном программировании много всякого гемора, и относительно плохие средства разработки. Так что заниматься этим делом трудно, потому что занудно и неудобно. Но вот какого-то мегаума и сверхспецподготовки, по сравнению с чем-то другим высококвалифицированным в программировании, эта область ИМХО не требует