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

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

Может сложиться неверное впечатление, что драйвер должен выбрать один из описанных способов вводагвывода и использовать только его. Драйвер, который выполняет операции управления вводом-выводом (IOCTL), может использовать один метод ввода-вывода для обработки обычных пакетов IRP и совершенно другой метод для операций управления вводом-выводом, которые определяются частным образом между драйвером и соответствующим приложением. Конечно, даже драйвер на нижних уровнях стека драйверов, который не имеет информации о контексте выполнения, не обязательно использует небуферизированный ввод-вывод в частных операциях управления вводом-выводом.

Поскольку здесь затронута тема частного управления вводом-выводом, стоит упомянуть, что компания Microsoft настойчиво советует не применять такой способ управления, особенно при наличии более приемлемой альтернативы. Основная проблема частного управления вводом-выводом заключается в сложности проверки “жизнеспособности” кода драйвера методом намеренной передачи некорректных буферов процедуре управления вводом-выводом, что делается для проверки работоспособности драйвера. Для передачи некорректного буфера необходимо иметь информацию о правильном размере буфера, выравнивании и граничных условиях, которые предполагаются в коде управления вводом-выводом, а для частных операций управления вводом-выводом эти параметры каждый раз имеют другие значения.

1.6.2 прямой ввод-вывод | Системы хранения данных в Windows | 1.7 иерархия драйверов систем хранения и типы драйверов


Системы хранения данных в Windows



Новости за месяц

  • Апрель
    2020
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31