Можно ли в драйвер-фильтр "воткнуть" перехватчик прерывания?

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

Тогда такой вопрос: Можно ли написать так свою Isr routine, чтобы можно было бы гарантировать, что при возникновении прерывания она будет всегда вызываться первой? Тогда просто надо будет возвратить FALSE и исходный драйвер потом сделает что надо и возвратит TRUE...

 

Ну, неужели так уж сложно перехватить прерывание под win 2000/XP?



Я думаю, что тут надо детально разобраться с функцией

NTSTATUS

IoConnectInterrupt(

OUT PKINTERRUPT *InterruptObject,

IN PKSERVICE_ROUTINE ServiceRoutine,

IN PVOID ServiceContext,

IN PKSPIN_LOCK SpinLock OPTIONAL,

IN ULONG Vector,

IN KIRQL Irql,

IN KIRQL SynchronizeIrql,

IN KINTERRUPT_MODE InterruptMode,

IN BOOLEAN ShareVector,

IN KAFFINITY ProcessorEnableMask,

IN BOOLEAN FloatingSave

);...



Может, кто-то это сделал уже до меня?

 

Тогда тебе надо изменить IDT и перехватить прерывание там.

Не забывай только о том, что есть SMP машины, а там несколько IDT и хукать надо значит в каждой из них.

 

ubil

какая разница в каком модуле будет осуществлен перехват, главное , чтоб он находился в режиме ядра

 

Ms Rem,

Может, есть какое-нибудь виндовзское средство? А то получается что-то вроде чуханья левого уха правой ногой(хотя я вот попробовал, правой даже удобнее чем левой))

Кстати, а что такое SPM? В Зубкове, вроде про это не было написано, когда я читал, по крайней мере.





CARDINAL,

Так ведь вопрос в том, чтобы перехватывающая Isr вызывалась ПЕРВОЙ, что в обычном случае не гарантированно.

А что если, к тому же исходный драйвер вызвал IoConnectInterrupt с параметром ShareVector = FALSE? По идее я тогда свою Isr вообще не смогу прикрепить

 

Ага, действительно правой даже удобнее чем левой. Если IoConnectInterrupt вызывать с параметром ShareVector = FALSE для уже установленого обработчика прерывания, то прикрепить свой действительно не удасться. Модифицировать IDT не сложно, и это гарантирует что твой обработчик будет вызван действительно первым.

А SMP - это мультипроцессорные машины, такими являются и HyperThreading процессоры. Код для корректной установки обработчика прерываний на такой машине смотри в multiprocessor.c в исходниках IceExt.

 

Ms Rem,

А можешь поконкретнее написать, где этот multiprocessor.c можно найти? (Ни в папках compuware, ни разных DDK, ни здесь на сайте я его не нашел)

А вот еще такой технический вопрос к тебе - основной код у меня будет на cpp, и мне тогда придется использовать ассемблерные вставки, чтобы вызывать привилегированные команды хотябы; так вот эта MSVS6.0, в которой я всегда работаю, в большинстве случаев почти сразу виснет намертво когда я набираю "__asm {", как же тогда быть? Мне что, теперь придется компилировать ассемблерный код отдельно, а потом прикреплять полученный obj к основному коду написанному на с++? Может, есть в DDK какие-нибудь функции или макросы типа KeGetIDT()?

 

ubil

multiprocessor.c в IceExt (он с сурсами)

 

MegaZu,

Што ест IceExt? Говорю же, что во всей папке compuware (NuMega SOFTICE Driver Suite) у меня нет никакого multiprocessor.c Может, я его уустановил как-то не полностью...

 

ubil

Плагин в софтайсу, ты хоть искать пробовал ??



Здесь

 

Так бы сразу и сказал, что это плагин. А я в исходниках искал

Спасибо

 

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

 

Я IceExt во встроенном редакторе FAR-а набирал.

Хотя сейчас подсел на Visual Assist и без него работать не могу. )



Можно порекомендовать установить VC 6.0 SP6. Никогда таких глюков с __asm не замечал.

 

Sten,

О, раз ты набирал IceExt, можешь мне посоветовать, где можно прочитать соответствующую документацию по программированию прерываний когда много процессоров?



Ms Rem,

Виснет, еще как виснет! Я пробовал и MSVS6.0 Enterprise ed., и pro, и на своем компе, и на другом( там 2 проца, кстати ) Особенно если сишиый код очень большой и если долго не закрывать фигурную скобку, то даже если ничего не нажимать потом(make, build, etc.), виснет c**ара

 

ubil, ага, почитай IA-32 Intel® Architecture

Software Developer’s Manual, Volume 3: System Programming Guide.

И первый том, в принципе, тоже можно.

 

Sten,

Все понятно, спасибо

 

ubil

Так ведь вопрос в том, чтобы перехватывающая Isr вызывалась ПЕРВОЙ, что в обычном случае не гарантированно.

А что если, к тому же исходный драйвер вызвал IoConnectInterrupt с параметром ShareVector = FALSE? По идее я тогда свою Isr вообще не смогу прикрепить







ну и тыкайся прямиком в таблицы

 

Я так понимаю если драйвер зарегистрировал свою процеДуру обработки прерывания и объявил его неразделяемым(FALSE)то подлезть к прерываню "культурно" с помощью IoConnectInterrupt невозможно, только через перезапись вектора в IDT.Если драйвер зарегистрировал процеДуру обработки прерывания и объявил его разделяемым(TRUE)то при подключении к этому прерыванию через IoConnectInterrupt любых других драйверов она выстраивает их в цепочку связанных обработчиков, и при поступлении прерывания с заданным номером система начинает идти по этой цепочке предлагая каждой зарегистрированной Isr обработать это прерывание. Как только одна из зарегистрированных процедур заявит права на обработку этого прерывания(вернет TRUE)цепочка разрывается, и остальным обработчикам не известно что прерывание уже случилось и обработано. Таким образом для гарантированного перехвата прерывания первым надо напрямую лезть и править адреса обработчиков в IDT, а про IoConnectInterrupt забыть. Когда-то я писал шаблон драйвера который подключается к любому прерыванию через редактирование IDT, и управляющее модальное окно. Исходники с документированием, все вместе порядка 20Мб, прикрепить не могу(трафик).Надо, пиши на мыло odyakov_dmitrii@mail.primorye.ru

P.S. но речи о поддержке SMP не идет...

 

Нифига себе. Интересно, чего же там на 20 мб то?

У меня на 5 кб получилось с поддержкой SMP, причем там не только прерывания, но и многое другое есть.

 

Ну я не знаю, это папка проекта для VC6.0 столько весит...