Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

kernel-mode и потоко-безопасный лог.

Страницы: < 1 2
Riply © (2008-09-22 09:53:00)
Здравствуйте !
Т.к. мое IMHO, что любое серьезное дело надо начинать с организации ведения лога, :)
приступила к изучению сабжевой темы.

Пожелания к нашему логу:
1. Потоко-безопасен.
2. При IRQL = PASSIVE_LEVEL ведет запись в файл ( ZwWriteFile )
и отправляет Dbg-сообщение ( DbgPrint )
3. При PASSIVE_LEVEL < IRQL <= DISPATCH_LEVEL только отправляет Dbg-сообщение.
4. В обоих случаях (DbgPrint и ZwWriteFile) , для формирования сообщения
используется заранее выделенная (при загрузке драйвера) память.

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

Посмотрела различные варианты, но так и не смогла выбрать нужный :(
А может не смогла понять из их описания, как с ними надо работать.
(Offtop: и когда же у нас появиться раздел "WinApi для начинающих" ?
ибо у меня ощущение, что я запуталась в основах )

Вот что меня смущает:

KEVENT:
Для его ожидания надо использовать KeWaitForXxx.
А в MSDN сказано:
"Callers of KeWaitForSingleObject must be running at IRQL <= DISPATCH_LEVEL.
However, if Timeout <> 0, the caller must be running at IRQL <= APC_LEVEL and in a nonarbitrary thread context."
Соответсвенно, он не очень нам подходит.

KMUTEX:
аналогичные возражения, кроме того MSDN рекомендует вместо них использовать FAST_MUTEX

FAST_MUTEX:
С ним, я совсем запуталась.
Функции типа ExAcquireFastMutexUnsafe требуют строгого(?) равенства IRQL = APC_LEVEL
А, если использовать ExAcquireFastMutex, то они нас автоматически
переведут из PASSIVE_LEVEL в APC_LEVEL.
Получается, что при их использовании, нам в принципе невозможно вызывать ZwWriteFile
т.к. она работает только в PASSIVE_LEVEL ?

KSPIN_LOSK:
Вообще страшная штука :)
Мало того, что нас перебрасывают в DISPATCH_LEVEL,
да еще Солдатов пишет, что "не рекомендуется удерживать объект спин-блокировки более 25 микросекунд"
Шарахаемся от них как от огня :)

ERESOURCE:
Вот, вроде то, что мы так долго искали.
Как я поняла:
1. они никуда нас не перебрасывают
2. имеют богатый набор функций для управления, из которых только функции типа
ExAcquireResourceExclusiveLite требуют IRQL <= APC_LEVEL, остальные же IRQL <= DISPATCH_LEVEL.
3. Да и вообще MSDN на все лады распевает, какие они прекрасные и производительные :)

Но, как всегда впрочем, мне кажется что "что-то здесь не то".
Например, Солдатов про них пишет:
"что исключительный доступ к данным, охраняемым объектом типа ERESOURCE,
реализуется через механизм спин-блокировок."
Т.е. они (такие вкусные) работают на том, от чего мы бежали как черт от ладана ?
Почему же их использование не несет тех же ограничений, что и KSPIN_LOSK ?

Игорь Шевченко (2008-09-26 12:58:00) [21]
Учитесь у Руссиновича - он плохому не научит

Игорь Шевченко (2008-09-26 12:58:00) [22]

> Перечислите параметры "интересного мусора" плз, аж интересно
> стало

ошибки, предупреждения, все, что требует внимания пользователя.
а когда оно замусоривается сообщения от SQL Server в какой операционной системе это чудо работает, то давить однозначно писателей.

Rouse_ (2008-09-26 11:25:00) [23]

> И такие сообщения идут на каждый его чих :)

В режиме отладки сообщений много не бывает :)

Riply (2008-09-26 11:16:00) [24]
> [9] Rouse_ © (26.09.08 11:01)
> Перечислите параметры "интересного мусора" плз, аж интересно стало :)

Саш, ты не читал лога моего драйвера :)
Он выглядит примерно так:
.......
"тут я пытаюсь создать символьную ссылку"
"тут я успешно создал эту символьную ссылку"
"ой ! а тут у меня вызвали такую-то процедуру"
.....
и т.д. и т.п. И такие сообщения идут на каждый его чих :)

Rouse_ (2008-09-26 11:01:00) [25]

> Давить всех, кто пишет в eventlog всякий неинтересный мусор

Перечислите параметры "интересного мусора" плз, аж интересно стало :)
Да и кстати. в чем проблема то? Заводим собственный журнал, чтоб Application или System не замусоривать и резвимся там вовсю :)

Игорь Шевченко (2008-09-26 10:48:00) [26]

> Как альтернативный вариант ведению логов записью в файл,
> можно воспользоваться записью в системный журнал ошибок

Давить таких писателей. Давить всех, кто пишет в eventlog всякий неинтересный мусор

Riply (2008-09-26 06:53:00) [27]
>[6] Thomas Anders (26.09.08 00:34)
>Как альтернативный вариант ведению логов записью в файл, можно воспользоваться записью в системный журнал ошибок.

Спасибо.

Thomas Anders (2008-09-26 00:34:00) [28]

> kernel-mode и потоко-безопасный лог

Как альтернативный вариант ведению логов записью в файл, можно воспользоваться записью в системный журнал ошибок. Позднее созданную запись можно просмотреть в Event Viewer. Ваша задача как разработчика драйвера - создать подходящие пакеты регистрации ошибок при возникновении события, заслуживающего внимания. См. в DDK функции IoWriteErrorLogEntry, IoAllocateErrorLogEntry.

Городской Шаман (2008-09-22 16:32:00) [29]
Ну драйвер filemon вообще никаких логов не ведет, он просто запоминает лог в буфере и приложение два раза в секунду опрашивает драйвер на предмет наличия данных в буффере.

Игорь Шевченко (2008-09-22 16:28:00) [30]

> NTWriteFile вообще-то должна работать при иных IRQL от Passive
> Level. Хотя не проверял.

Не должна. Результатом будет любимая надпись IRQL IS NOT LESS OR EQUAL

Автору: От всех ошибок спасает Driver Verifier, а вообще методика таких логов очень хорошо описана в исходниках filemon, regmon и иных изделиях Руссиновича и Когсуэлла.

Городской Шаман (2008-09-22 16:22:00) [31]
Ну есть NTWriteFile. Вот её заголовки(те же самые как у ZwWriteFile)

function NtWriteFile(
FileHandle : HANDLE;
Event : HANDLE;
ApcRoutine : PIO_APC_ROUTINE;
ApcContext : PVOID;
IoStatusBlock : PIO_STATUS_BLOCK;
Buffer : PVOID;
Length : ULONG;
ByteOffset : PLARGE_INTEGER;
Key : PULONG
): NTSTATUS; stdcall;

NTWriteFile вообще-то должна работать при иных IRQL от Passive Level. Хотя не проверял.

Riply (2008-09-22 14:39:00) [32]
> [1] Городской Шаман (22.09.08 14:10)
> А разве NtCreateFile не будет работать при уровне IRQL APC или DPC?

Вообще-то CreateFile меня не очень интересует (создали и забыли :), мне нужна ZwWriteFile.
А про нее в MSDN написано:
"Callers of ZwWriteFile must be running at IRQL = PASSIVE_LEVEL and with APCs enabled."

Городской Шаман (2008-09-22 14:10:00) [33]
А разве NtCreateFile не будет работать при уровне IRQL APC или DPC?

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »