Поделиться через


Модель связи, синхронизация и прерывание

На высоком уровне в этой документации определены два типа объектов:

  1. Адаптер, представляющий устройство Wi-Fi.
  2. Порт, представляющий различные сущности MAC и PHY в адаптере.

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

Команды свойств — это простые команды (например, получение силы сигнала, получение текущего списка BSS и установка фильтра пакетов). Они выполняются за короткий промежуток времени и не являются сложными в реализации.

Команды задач — это сложные операции, выполнение которых может занять несколько секунд. Например, операция сканирования Wi-Fi будет классифицироваться как задача в этой модели.

Все команды, выданные компоненту IHV, можно выполнять асинхронно.

Последовательность сообщений

Последовательность сообщений для каждого типа команды показана на следующих рисунках.

На рисунке 1 показана последовательность команд задач.

Поток задач команды wdi.

На рисунке 2 показан поток команд свойства.

Поток команд свойств wdi.

На рисунке 3 показан поток индикации.

Поток индикации wdi.

Синхронизация

Чтобы упростить реализацию компонента IHV, модель определяет следующие правила синхронизации:

  1. Команды всегда сериализуются между шагами 1 и 3 на рис. 1 и 2. Например, новые команды не выдаются адаптеру до указания адаптера на шаге 3. Это также означает, что все свойства сериализуются друг с другом.
  2. Все команды задачи сериализуются между шагами 1 и 4 на рис. 1. Например, одновременно на адаптере выполняется только одна задача. Однако после запуска задачи (шаг 3 на рис. 1) адаптер может получить запросы к командам свойства. Шаг 3 и шаг 4 должны быть завершены до отправки следующей команды задачи.
  3. Команды набора свойств имеют два типа: команды, которые можно отправлять после запуска задачи, и команды, которые необходимо сериализовать с ожидающими задачами.
  4. Путь к данным не сериализуется с помощью пути команды, за исключением конкретных случаев, описанных далее в документации.
  5. Область синхронизации — область уровня адаптера.
  6. Подмножество задач можно прервать после их запуска. Это означает, что если задача с более высоким приоритетом (A) прибывает, а задача с более низким приоритетом (B) не выполняется, узел может прервать B. Рационализация решений о определении приоритетов выходит за рамки область этой документации и зависит от пользовательских сценариев.
  7. Для команд задач шаг 4 может выполняться до завершения шага 3. Однако если указан шаг 4, шаг 3 не может завершиться ошибкой.

Прерывание

Большинство задач можно прервать после их запуска. Целью прерывания является активация адаптера для быстрого завершения задачи путем отправки полного указания (шаг 4 на рис. 1). Прерывание допускается только в окне между шагами 3 и 4 на рис. 1. При получении прерывания адаптер должен выполнить задачу в течение 50 миллисекунд. Для большинства команд после получения прерывания адаптеру не нужно выполнять откат до состояния перед запуском команды. Между выполнением команды прерывания и завершением, поступающим в компонент узла, существуют условия гонки. В этом случае, если компонент IHV получает прерывание для уже завершенной задачи, от компонента IHV не требуется никаких дополнительных действий для обработки операции прерывания. Прерывание задачи — это просто сигнал о том, что компонент IHV должен как можно скорее очистить задачу. Семантика завершения команд не изменяется при выполнении прерывания. Во всех случаях необходимо соответствующим образом уведомлять о завершении команды свойства прерывания и о завершении задачи.

Ожидается, что свойства завершатся в течение короткого времени, поэтому их нельзя прервать.

Команды задач имеют уникальный идентификатор, который позволяет узлу нацеливать определенную команду для прерывания.