Какой тип DPC следует использовать?

В зависимости от дизайна драйвера он может иметь любой из следующих элементов:

• Один DpcForIsr для выполнения всех операций ввода-вывода, управляемых прерыванием

• Набор одной или нескольких подпрограмм CustomDpc .

• И DpcForIsr, и набор подпрограмм CustomDpc для конкретной операции

Независимо от того, имеет ли драйвер одну подпрограмму DpcForIsr , набор подпрограмм CustomDpc или оба, зависит от характера базового устройства и набора запросов ввода-вывода, которые он должен поддерживать.

Большинство драйверов устройств низкого уровня имеют одну подпрограмму DpcForIsr для завершения обработки ввода-вывода для каждого IRP, требующего одной или нескольких операций на соответствующих устройствах. Использование одного DpcForIsr для завершения операций ввода-вывода, управляемых прерываниями, по запросу на устройстве, выполняющем одну операцию за раз, является относительно простой задачей. Такой ISR драйвера должен вызывать только IoRequestDpc для каждой операции ввода/вывода, вызванной прерыванием.

Немногие драйверы с низким уровнем имеют подпрограммы CustomDpc , если их устройства не требуют более одного DPC для выполнения различных операций ввода-вывода на основе прерываний.

Использование одного DpcForIsr для завершения перекрывающихся операций ввода-вывода, управляемых прерываниями, на устройстве, способном выполнять параллельные операции, возможно при тщательном проектировании, однако это может быть относительно сложной задачей. Помимо или вместо размещения в очередь DpcForIsr, ISR может поставить в очередь набор подпрограмм CustomDpc, предоставленных драйвером, вызвав KeInsertQueueDpc.

Например, рассмотрим некоторые проблемы проектирования, связанные с написанием серийного драйвера. Будучи драйвером полного дуплексного устройства, последовательный драйвер не может полагаться на один-к-одному соответствие между порядком, в котором IRPs поступают в подпрограмму StartIo, и последовательностью прерываний с устройства в многозадачной многопроцессорной системе. Кроме того, последовательные драйверы должны обрабатывать запросы времени ожидания и асинхронные запросы, созданные пользователем, чтобы отменить ранее запрошенные операции, чтобы очистить буферизованные данные и т. д.

Следовательно, последовательный драйвер может поддерживать внутренние очереди для операций чтения, записи, очистки и ожидания, которые могут запрашивать приложения com-портов в режиме пользователя. Кроме того, он может вести учет ссылок или использовать другой механизм отслеживания, например набор флагов, для IRPs во внутренних очередях. Его ISR вызовет KeInsertQueueDpc с любым из нескольких выделенных и инициализированных объектов DPC драйвера, каждый из которых связан с подпрограммой CustomDpc , предоставленной драйвером.