ama_kid, никак не могу понять:
Вот пишем мы лог из Dispatch функций.
А на чем основана наша уверенность в том, что это потоко-безопасно ?

Хм... Для начала два встречных вопроса:
1) Я где-нибудь это утверждал?
2) Я где-нибудь использовал потоки?
Естественно, разработка многопоточных приложений может наложить свой отпечаток, в том числе и в режиме ядра, но все-таки это не является предметом рассмотрения в даной статье... Ну а ответом на поставленный вопрос, думаю, может служить тот факт, что посылка запросов IRP_MJ_READ\WRITE\DEVICE_CONTROL осуществляется синхронно, т.е. системный менеджер запросов не пошлет драйверу следующий IRP-пакет до тех пор, пока им не будет обработан предыдущий. Поэтому, допустим, вызов ReadFile из одного потока при обработке ReadFile из другого потока вызовет просто задержку на исполнение первого вызова. Отчасти поэтому и не рекомендуется задерживать обработку IRP-пакетов (а на высоких уровнях приоритета - вообще нельзя) - т.к. это приводит к performance reducing...

Это смотря что считать утверждением   
Я посчитала, что раз ты не побеспокоился о потоко-безопасности,
значит считаешь, что это излишне. Вот я и пыталась понять на чем это заключение основано   



Спасибо. Именно это меня и интересовало.
Т.е. сколько бы приложений одновременно не открыло наше устройство для связи с драйвером
и с какой интенсивностью они бы ни читали(писали) мы будем получать только по одному запросу
и пока его не обработаем, следующий нам никто не даст.
Я правильно поняла ?

Да на таком уровне и беспокоиться не надо - BSOD быстренько бы обо всём напомнил   
вполне  

И очень похоже, что ты оказался прав в своем выборе 

Вот что гласит MSDN:
To allocate I/O buffer space, the best memory allocation routines to use are MmAllocateNonCachedMemory, MmAllocateContiguousMemorySpecifyCache, AllocateCommonBuffer (if the driver's device uses bus-master DMA or a system DMA controller's auto-initialize mode), or ExAllocatePoolWithTag. 

Nonpaged pool typically becomes fragmented as the system runs, so a driver's DriverEntry routine should call these routines to set up any long-term I/O buffers the driver needs. Each of these routines, except ExAllocatePoolWithTag, allocates memory that is aligned on a processor-specific boundary (determined by the processor's data-cache-line size) to provide best performance. 



Это сообщение отредактировал(а) Riply - 12.9.2008, 04:29

ama_kid,  что-то мне не удается найти в ntoskrnl.lib ничего похожего
на KeGetCurrentIrql :(

Может она называется там совсем по-другому ?
Подскажи, пожалуйста, как ее импортировать ?

Потому что она импортируется из wdm.lib. Смотри аттач (а по-хорошему, просто поставь себе DDK   )

Это сообщение отредактировал(а) ama_kid - 16.9.2008, 19:12

Присоединённый файл ( Кол-во скачиваний: 36 )
 wdm.lib 186,21 Kb

Спасибо. Скачала, буду смотреть.



С DDK мы еще не знакомы. Пока не разобралась с какой стороны к нему подходить 

ama_kid, 

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

Выдержка из лога Dbgview:
00000034  11:43:50  DriverRead _ 0 0 0    
00000035  11:43:50  DriverRead IoCallDriver 103 0 0    
-->00000036  11:43:54  DriverUnload _ 0 0 0    
00000037  11:43:56  DRIVER_NAME : DriverReadCallBack    
00000038  11:43:56  DriverUnload KeWaitForSingleObject 0 0 0    
00000039  11:43:56  DriverUnload ZwClose 0 0 0    
00000040  11:43:56  DriverRead _ 0 0 0    
00000041  11:43:56  DriverUnload IoDeleteSymbolicLink 0 0 0    
00000042  11:43:56  DriverRead IoCallDriver 103 0 0    
00000043  11:43:56  DriverUnload IoDetachDevice 0 0 2262795872    
00000044  11:43:56  DriverUnload IoDeleteDevice 0 0 2240838328    
00000045  11:43:56  SnakeLog Finalizate 0 43 1024    

Соответствующие строчки из лога KbdIntcpt:
0000000748    21.09  07:43:50.500 DriverRead    IoCallDriver    Overlapped I/O operation is in progress ( $000003E5 )    0000000000    0000000000    0000000025    0000000046
-->0000000052    21.09  07:43:54.062 DriverUnload    _    The operation completed successfully    0000000000    0000000000    0000000026    0000000047
0000000052    21.09  07:43:56.593 DriverUnload    KeWaitForSingleObject    The operation completed successfully    0000000000    0000000000    0000000027    0000000048
0000000052    21.09  07:43:56.593 DriverUnload    ZwClose    The operation completed successfully    0000000000    0000000000    0000000028    0000000049
0000000748    21.09  07:43:56.593 DriverRead    IoCallDriver    Overlapped I/O operation is in progress ( $000003E5 )    0000000000    0000000000    0000000031    0000000051
0000000052    21.09  07:43:56.593 DriverUnload    IoDetachDevice    The operation completed successfully    0000000000    2262795872    0000000032    0000000052
0000000052    21.09  07:43:56.593 DriverUnload    IoDeleteDevice    The operation completed successfully    0000000000    2240838328    0000000033    0000000053
0000000052    21.09  07:43:56.593 SnakeLog    Finalizate    The operation completed successfully    0000000043    0000001024    0000000034    0000000054

"-->"    - помечен вход в процедуру DriverUnload
Видно, что паралельно с ней у нас отрабатывает и процедура DriverRead,
причем работают они "из разных потоков" (ID одного - 52, другого - 748).
Т.е. у нас получается следующая последовательность действий:
DriverUnload -->   KeWaitForSingleObject
DriverUnload -->   ZwClose
DriverRead --> входим в процедуру
DriverUnload -->   IoDeleteSymbolicLink
DriverRead --> IoCallDriver
DriverUnload -->   IoDetachDevice
DriverUnload -->   IoDeleteDevice

Вот такие пироги.

P.S.
 Очень надеюсь, что ты найдешь ошибку в рассуждениях и мне не придется
 разбираться еще и потоко-безопасностью,  вместо похода на дискотеку 

P.P.S.
 У меня еще возникли вопросы по работе с памятью, но это после того как с этим разберемся 

Добавлено через 5 минут и 1 секунду
Вот черт. У меня такие аккуратные таблички были, а тут все съехало.
Sorry. 
Надеюсь они стали не очень нечитабельны   

Если кому интересно...  

Попробовала чуть более детально разобраться с нашей потоко-безопасностью.
Вот что получилось:
Для синхронизации выбрала (после очень долгих и тяжких раздумий) объект ERESOURCE.
(Выбирала с учетом своих планов, так что кому-то может лучше подойдут объекты другого типа)
Эффект искажения данных в логе исчез сразу после заключения 
"логовых" функций в "критические обертки".
Для проверки, что одновременная запись в лог разными нитями мне не померещилась
в кошмарном сне , чуть изменила стандартный код вхождения в критический регион на нечто такое:


Вот выдержка из лога Dbgview:
 
00000043   07:48:45.484   DriverRead IoCallDriver 103 0 Free    
00000044   07:48:45.562   ReadCompleteCallback    
00000045   07:48:45.562   DriverRead _ 0 0 Free    
00000046   07:48:45.562   DriverRead IoCallDriver 103 0 Free    
00000047   07:48:48.718   DriverUnload _ 0 0 Free    
00000048   07:48:50.859   ReadCompleteCallback    
00000049   07:48:50.859   DriverUnload KeWaitForSingleObject 0 0 Free    
00000050   07:48:50.859   DriverUnload ZwClose 0 0 Free    
00000051   07:48:50.859   DriverRead _ 0 0 Locked(!)    
00000052   07:48:50.859   DriverUnload IoDeleteSymbolicLink 0 0 Locked(!)    
00000053   07:48:50.859   DriverRead IoCallDriver 103 0 Locked(!)    
00000054   07:48:50.859   DriverUnload IoDetachDevice 0 0 Free    
00000055   07:48:50.859   DriverUnload IoDeleteDevice 0 0 Free    
00000056   07:48:50.859   LatchFile LatchFile_Finalizate 0 38 1024

Как мне кажется, из нее (выдержки) видно как происходит борьба двух нитей за ресурс 

P.S.
 То, что мне помогло использование ERESOURCE (это утверждение основано на отсутствии 
 BSOD в течении трех часов ), вовсе не означает, что путь правильный.
 Требуется более тщательная проверка.    

Ой, что-то как-то я упустил свою тему из виду, извиняюсь, просто уже несколько дней не заглядывал на форум...   
Имхо, нет в твоих рассуждениях ошибки, насколько я разобрался в той каше, которую ты вывалила 
Насколько я понял, у тебя вызвал непонятки момент одновременной записи в лог из DriverRead и DriverUnload? Не забывай (или имей ввиду), что функции DriverEntry и DriverUnload - это не функции-диспетчеры, а функции, выполняющиеся в контексте одного из системных потоков (случайным образом выбирается один из потоков процесса SYSTEM). А функции-диспетчеры выполняются в контексте процесса, выполняющего запрос ввода-вывода . А раз так - то для синхронизации между функциями-диспетчерами и системным потоком конечно нужно использовать объекты синхронизации...

Кроме того, меня смутила твоя фраза про "немного переделанный вариант" KbdIntcpt. Насколько я понял, ты ввела Overlapped-режим? Если я правильно помню - то отложенные операции выполняются тоже в контексте системного потока (аналогично callback-функциям), поэтому между двумя системными потоками тоже неплохо бы вводить синхронизацию при использовании ими общих ресурсов   

hi, all 
Относительно темы delphi драйверов...

Надо отметить что некоторым недостатком является  сборка драйверов из obj-ектников, или использованием сторонних тулз (omf2d, m$-link).

Вобщем куда удобней использовать собственный линкер delphi, устраняя некоторые неровности в производимых им PE dll-ках, таким вот напильником: 



Дабы компиль не напихал вредных зависимостей, разюмеется для сборки необходимы минимальные System/Sysinit





Особености реализации модулей позволяют использовать блоки try/except  (хотя от всех видов исключений (например GPF) - они не спасут). 

Ну и собственно как использовать:


удачи 

Использую DDDK0004 

Никак не пойму почему bsod. Пробую пообщаться с IO-APIC


вылитает на этих строчках. Может кто подскажет в чем дело?

А еще dbgprint не работает. 

Судя по всему срыв стека. Такое впечатление что неправильно экспортирую функции.

ama_kid
Спасибо! Отличная инфа!

microxa, 
Т.е. ты собираешь ДЛЛ и используешь ее как драйвер?
Какую версию Делфи ты используешь?
Потому что слышал, если собирать МС линкером, то он понимает обьектники только 3-й Делфи, т.к. после 3-й пошел неправильный COFF формат... И спасибо за System/SysInit, я юзал несколько попроще, без поддержки исключений