Привет,

Решил написать драйвер для Windows для простой карточки и сижу читаю пару книжек Oney и Солдатова. вообщем ломаю голову и попиваю чаек. Вроде бы понемногу все становится ясным, так что скоро уже начну что-нибудь писать, а вернее ломать какой-нибудь более подходящий

Хотелось бы спросить о StartIo c очередью необработанных запросов
1. Пусть карточка не имеет прерываний и DMA. Если карточка быстрая ( при запросе драйвер читает пару — тройку регистров, что-то немного вычисляет и отдает ответ), то я так понимаю, что мне не надо StartIo. Также если придет несколько запросов диспечеру ввода-вывода, то он обеспечит очередность к драйверу. Прав ли я? Если какие-нибудь временные критерии для этого?

Если же карточка медленная (запустила и что-то ждет), то мне надо StartIo и все остальное хозяйство к ней.

2. Пусть карточка имеет еще и прерывание, но не имеет DMA.
Карточка у меня быстрая, но на входе у нее приходят события, которые перезаписывают данные. Это связано с прерыванием. В этом случае прикладная программа может захотет "проснуться" по приходу события от прерывания. Это тоже не связано с StartIo?

3. Ну с DMA карточка по определению медленная. Поэтому нужна и StartIo.

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

V>Хотелось бы спросить о StartIo c очередью необработанных запросов
V>1. Пусть карточка не имеет прерываний и DMA. Если карточка быстрая ( при запросе драйвер читает пару — тройку регистров, что-то немного вычисляет и отдает ответ), то я так понимаю, что мне не надо StartIo. Также если придет несколько запросов диспечеру ввода-вывода, то он обеспечит очередность к драйверу. Прав ли я? Если какие-нибудь временные критерии для этого?

Диспетчер очередности к драйверу обеспечивать не будет. Если в процессе обработки одного запроса на другом процессоре будет выдан еще один запрос — диспетчерская функция драйвера будет вызвана немедленно, и обе какое-то время будут работать параллельно.

StartIo — это просто стандартный системный способ постановки запросов в очередь. Если он не нравится — можете сами ставить запросы в очередь и отдавать STATUS_PENDING, а обрабатывать по прерываниям от устройства/таймера.

ВременнЫх критериев, как таковых, нет — все упирается в ожидания. То есть, если драйверу не требуется ожидать какого-то события, и для обработки запроса достаточно каких-то преобразований данных — это синхронный запрос, он должен завершаться без постановки в очередь. Если требуется ожидание — запрос асинхронный, он должен запоминаться для обработки и помечаться, как ждущий (pending).

В книжках пишут о возможных вариантах передачи даннах из/в драйвер. Когда читаешь, то возникает ощущение, что это это медленно и наверное для некоторого пусть и небольшого, но массива данных. Ес-но в голове сидит назойливый вопрос, а может как-то 1-2-4-8 байтов можно передать в передаваемых структурах (хотя этого места не видно).
Ну так что — есть дыра или действительно нету?

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

V>В книжках пишут о возможных вариантах передачи даннах из/в драйвер. Когда читаешь, то возникает ощущение, что это это медленно и наверное для некоторого пусть и небольшого, но массива данных. Ес-но в голове сидит назойливый вопрос, а может как-то 1-2-4-8 байтов можно передать в передаваемых структурах (хотя этого места не видно).

В запросах IRP_MJ_READ/IRP_MJ_WRITE можно передать два DWORD'а (ByteOffset), что соответствует полям Offset и OffsetHigh структуры OVERLAPPED. Эти поля иногда удобно использовать при передаче дополнительных параметров вместе с буфером, но для передачи "голых" данных они не годятся — буфер-то все равно нужен. Данные небольших размеров нужно передавать через METHOD_BUFFERED — расходы на копирование ничтожны по сравнению с расходами на цикл обработки запроса.