Таджикистан, Душанбе, Таджикский Технический Университет (ТТУ), 2013 |
Архитектура встраиваемой ОС реального времени – CE 6.0
Драйверы режима пользователя
Назначение Инфраструктуры драйвера (устройства) режима пользователя состоит в том, чтобы позволить загрузить промежуточный драйвер в режиме пользователя. Драйвер режима пользователя не сможет обратиться к оборудованию непосредственно. Для некоторых драйверов этот метод взаимодействия будет увеличивать стабильность системы. Отображение виртуальной памяти используется для защиты ядра от программ режима пользователя. Защита памяти ядра обеспечивается тем, что драйвер выполняется в режиме пользователя.
Инфраструктура драйвера режима пользователя делится на два физических компонента. Первым компонентом является Рефлектор драйвера режима пользователя (User Mode Driver Reflector), который располагается в менеджере устройства. Вторым компонентом является Хост драйвера режима пользователя (User Mode Driver Host), который является приложением режима пользователя, которое запускается и управляется Рефлектором драйвера режима пользователя. С точки зрения пользователя рефлектор заставляет драйверы режима пользователя работать, как если бы они были драйверами режима ядра.
Когда драйвер отмечен в реестре как драйвер режима пользователя, менеджер устройства будет обращаться к Рефлектору драйвера режима пользователя. Рефлектор драйвера режима пользователя запускает соответствующий процесс Хоста драйвера режима пользователя и пересылает в него запросы В/В. Процесс Хоста драйвера режима пользователя в свою очередь пересылает запросы В/В в Драйвер режима пользователя.
Процесс использования Драйвера режима пользователя начинаются с приложения пользователя или с драйвера шины предка. Приложения пользователей и драйверы шины предка могут загружать Драйверы режима пользователя, вызывая функции ActivateDevice или ActivateDeviceEx. Приложения пользователя и драйверы шины предка могут выгрузить Драйверы режима пользователя, вызывая функцию DeactivateDevice. После загрузки любое приложение пользователя или драйвер могут обратиться к Драйверу режима пользователя, вызывая указатель устройства.
Если драйвер является Драйвером режима пользователя, обращение к ActivateDevice или ActivateDeviceEx приведет к тому, что менеджер устройств вызовет также функцию Рефлектора драйвера режима пользователя. Драйвер распознается как Драйвер режима пользователя, когда значение FLAGS задано как DEVFLAGS_LOAD_ AS_USERPROC (0x10) в ключе устройства в реестре.
Рефлектор драйвера режима пользователя, который знает об исходном процессе и процессе места назначения, использует CeFsIoControl для пересылки запроса менеджера устройства Хосту драйвера режима пользователя. Хост драйвера режима пользователя затем анализирует запрос, чтобы загрузить, выгрузить, или вызвать точку входа драйвера шины предка.
Драйвер режима пользователя имеет ограниченные права доступа к оборудованию, что не позволяет ему размешать такие запросы, как отображение физической памяти или вызов функций прерываний.
Чтобы выполнить запросы такого типа, Драйвер режима пользователя вызывает Рефлектор драйвера режима пользователя, и активирует Рефлектор драйвера режима пользователя для обработки запроса. Рефлектор драйвера режима пользователя затем проверяет запрос пользователя согласно настройкам реестра, чтобы определить, должен ли он выполнить запрошенное действие. В отличие от прерываний и отображения физических адресов Драйвер режима пользователя может, через указатель устройства и без помощи Рефлектора драйвера режима пользователя, обратиться к драйверу шины предка, независимо от того, где находится драйвер шины предка.
Реестр
Реестр является системной базой данных, которая хранит информацию конфигурации для приложений, драйверов, и операционной системы. Для прикладных программ реестр наиболее часто используется для хранения информации состояния между вызовами. Например, приложение может иметь окна, которые пользователь может перемещать и изменять в размере. Перед выходом приложение может сохранить в реестре свою информацию об окнах. Затем, когда приложение запускается снова, оно может извлечь информацию и разместить соответственно его окна. ОС использует также информацию в реестре для поиска и загрузки драйверов устройств, когда появляется новое устройство с горячим подключением. Приложения пользователей, написанные для выполнения на нескольких устройствах, могут запрашивать реестр для определения, какое оборудование присутствует на устройстве.
Структура реестра CE аналогична реестру настольных версий Windows. Реестр содержит множество поддеревьев данных. Каждое поддерево состоит из ветвей, называемых ключами, и каждый ключ может содержать подключи и/или записи. Записи хранятся как пары имя/значения. В основании каждого поддерева находится корень, который определяется с помощью хорошо-известного константного значения, или HKEY.
Таблица 6.5 показывает корневые константы, поддерживаемые в CE, и краткое описание каждой:
Корневая ключевая константа | Описание |
---|---|
HKEY_CLASSES_ROOT | Хранит соответствие типов файлов и данные конфигурации OLE. |
HKEY_CURRENT_USER | Хранит специфические данные пользователя, который зарегистрирован в системе в данный момент. Это корневые точки к соответствующему ключу из HKEY_USERS. Сделанные изменения автоматически делаются в ключе пользователя в HKEY_USERS. |
HKEY_LOCAL_MACHINE | Хранит специфические для машины данные и конфигурационную информацию для драйверов устройств и приложений. |
HKEY_USERS | Хранит данные для всех пользователей, включая пользователя по умолчанию. |
Базовый фрагмент данных, который хранится в реестре, называется значением. Значение может быть различного типа, включая строку или двоичное значение. Каждое значение имеет имя и соответствующий фрагмент данных. Например, устройство которое выполняет программное обеспечение CE Handheld PC, Professional Edition, использует имя значения Wrap to Window в ключе HKEY_LOCAL_MACHINE\Software\Microsoft\Pocket Word\Settings для хранения целочисленного фрагмента данных для версии Pocket Word.
Большинство операций реестра использует функции реестра. Реестр CE экспортирует функции реестра Win32 для приложений для вызова для записи или для доступа к данным времени выполнения и других. Используйте реестр для хранения данных, которые требуются приложению для каждого сеанса. Например, можно сохранить состояние приложения во время процесса выключения. При запуске приложение может восстановить предыдущие настройки. Пространство реестра ограничено, поэтому пользователи должны минимизировать использование реестра их приложениями только несколькими ключами и упаковывать данные в битовые поля, если нужно минимизировать число требуемых ключей.
CE поддерживает два типа реестров, на основе RAM и на основе улья (hive). По умолчанию CE 6.0 реализует реестр на основе улья. Тип реестра невидим для приложений, но изменяет сохраняемость, последовательность загрузки, скорость, и использование памяти на используемом устройстве. Выбор типа реестра и настроек реестра влияет также на поведение профилей пользователей. Предоставляется специальная утилита, называемая Regedit, для редактирования реестра в Platform Builder. Platform Builder генерирует начальные записи реестра для используемого устройства вместе с кодом образа ОС.
Поддержка профиля пользователя имеется во всех конфигурациях файловой системы. Никакие компоненты для использования профилей пользователей добавлять не требуется.
Реестр на основе RAM
Реестр на основе RAM хранит все данные реестра в хранилище объектов. Это эффективно в терминах скорости и размера в устройствах, которые имеют RAM с питанием от батареи. Устройства, которые не поддерживают питание RAM во время выключения, должны копировать реестр во время выключения и восстанавливать реестр при включении питания. Реестр на основе RAM предназначен для использования в устройствах, которые часто используют теплую загрузку, но редко или никогда холодную загрузку.
Реестр на основе улья
Реестр на основе улья хранит данные реестра в файлах, или ульях, которые могут храниться в любой файловой системе. Это исключает необходимость выполнения резервного копирования и восстановления при выключении питания. Исключение этой работы во время загрузки и выключения питания делает процесс холодной загрузки быстрее.
Каждый файл или улей содержит совокупность данных реестра. Реестр на основе улья делится на два улья: системный улей, который содержит все системные данные, и улей пользователя, который содержит все данные, имеющие отношение к одному определенному пользователю. Многопользовательские системы будут содержать несколько ульев пользователей. Улей пользователя будет присоединяться при регистрации в системе и отсоединяться при выходе.
Регистр на основе улья предназначен для использования на устройствах, которые часто используют холодную загрузку, но редко или никогда теплую. Он также полезен на устройствах, которые требуют поддержку нескольких пользователей.
Улей является группой ключей, субключей, и значений в реестре, которые имеют множество поддерживающих файлов, содержащих резервные копии данных из улья. Улей интерпретируется как одна единица и сохраняется и восстанавливается как один файл.
Менеджер устройств
Менеджер устройств (Device Manager) загружается ядром, он выполняется непрерывно, и управляет загруженными драйверами устройств и их интерфейсами. Когда загружается Менеджер устройств, он загружает также Менеджер ресурсов (Resource Manager) В/В для чтения списка доступных ресурсов из реестра.
Менеджер устройств отслеживает интерфейсы, предоставляемые драйверами, и поддерживает поиск драйверов на основе глобально уникального идентификатора (GUID). Интерфейс IClass может связать интерфейс GUID с унаследованным именем драйвера, его именем $device, или его именем $bus. Например, COM1:, $device\com1, или $bus\pci_0_3_0.
Менеджер устройств является процессом, который выполняется в операционной системе CE, отслеживая загруженные драйверы и их интерфейсы. Он выполняется постоянно и запускается из ядра. Менеджер устройств может уведомлять пользователя, когда интерфейсы устройств становятся доступны и недоступны. Пользователь или сама система может делать интерфейсы устройств доступными или недоступными. Кроме того, Менеджер устройств уведомляет ядро, что интерфейс устройства поддерживает файловые операции, такие как
CreateFile для доступа к устройствам, которые предоставляет потоковый интерфейс. Менеджер устройств посылает обратные вызовы уведомления о питании драйверам устройств и предоставляет службы управления питанием.
Менеджер устройств управляет ключом Active в реестре. Только Менеджер устройств должен обращаться к ключу Active для доступа по чтению или записи. Можно неявно обратиться к ключу Active через параметр функции инициализации драйвера устройства.
Менеджер устройств ищет ключ реестра HKEY_LOCAL_MACHINE\Drivers\RootKey, чтобы определить ключ для начала обработки загрузки драйвера. Значением по умолчанию для RootKey является Drivers, но оно обычно задается как Drivers\BuiltIn. Менеджер устройств вызывает ActivateDeviceEx для загрузки драйвера, определенного значением подключа Dll, находящегося в ключе, определенном значением RootKey.
Значение подключа Dll по умолчанию будет BusEnum.dll, называемое также перечислителем шины. Загрузка BusEnum.dll вызывает загрузку всех драйверов устройств. Устройство, загруженное функцией ActivateDeviceEx, может прочитать его указатель активации из его ключа реестра Active.
Менеджер устройства связывает имя шины с драйверами. Неименованные устройства также могут иметь имя шины, так как даже если приложения могут не иметь доступа к драйверу, драйвер может быть доступен другим драйверам или системным объектам, таким как Менеджер питания. Имя шины может иметь ACL отличный от обычного имени устройства.
Драйверы могут программным путем объявлять интерфейсы, вызывая DMAdvertiseInterface. Функция DMAdvertiseInterface позволяет драйверам добавить дополнительные GUID для поиска в их соответствующих списках. DMAdvertiseInterface предоставляет библиотека Devmgr.dll, которая также реализует большую часть функций Менеджера устройств. Так как только Менеджер устройств может загрузить Devmgr.dll, только драйверы устройств могут вызывать DMAdvertiseInterface. Если драйвер устройства не объявляет о недоступности своих интерфейсов, когда драйвер выгружается, Менеджер устройств автоматически очищает уведомление объявления интерфейса.
Компоненты менеджера устройств
Менеджер устройств состоит из Device.exe и Devmgr.dll. Device.exe содержит библиотеку Devmgr.dll, которая реализует базовые функции Менеджера устройств. Так как Менеджер устройств состоит из двух отдельных модулей, драйверы устройств могут соединяться непосредственно с Менеджером устройств и вызывать определенные функции, такие как DMAdvertiseInterface, не создавая накладных расходов системного вызова. Таблица 6.6 показывает компоненты Менеджера устройств.
Компонент | Описание |
---|---|
devcore | Предоставляет базовые функции Менеджера устройств. |
iorm | Предоставляет функции менеджера ресурсов В/В. Iorm является требуемым компонентом и не может быть уделен. |
pmif nopmif Pmif | Предоставляет интерфейс к точкам входа DLL Менеджера питания. Nopmif предоставляет версию с заглушками точек входа Менеджера питания. |
Драйвер устройства является программой, которая абстрагирует функции физического или виртуального устройства. Драйвер устройства управляет работой этих устройств. Различные процессы загружают различные драйверы. Таблица 6.7 показывает процессы, которые загружают драйверы, и какие драйверы загружает каждый процесс.
Менеджер ресурсов В/В
Когда система загружается, перечислитель шины перечисляет рееестр и загружает все встроенные устройства, на основе этой информации из реестра. Можно сконфигурировать эту информацию реестра. Менеджер ресурсов В/В затем отслеживает текущее состояние доступных в системе ресурсов, и управляет всеми дальнейшими запросами и распределениями ресурсов В/В драйверов шины. Следовательно, все драйверы шины должны запрашивать ресурсы В/В у менеджера ресурсов В/В, когда они загружают драйвер клиента для устанавливаемых устройств или других типов устройств.
Менеджер ресурсов В/В является неотъемлемой частью Менеджера устройств. Менеджер ресурсов В/В отслеживает доступные системные ресурсы, инициализированные из реестра перед загрузкой каких-либо устройств. Отслеживание этих ресурсов предотвращает случайные коллизии, когда два или несколько драйверов попытаются использовать одни и те же ресурсы.
OAL и реестр обычно предварительно распределяют ресурсы пространства В/В и IRQ, которые запрашивают драйверы шины. Однако Менеджер ресурсов В/В не ограничен управлением пространствами В/В и IRQ. Определенное множество доступных ресурсов может включать все, что вы определяете. Драйверы шины, такие как драйвер шины PCI, ресурсы запроса пространства В/В и IRQ у Менеджера ресурсов В/В, когда он загружает драйверы устройств для устройств, которые находит. То же самое справедливо для драйвера шины PC Card и ресурсов В/В, требуемых драйверам клиентов PC Card. Драйвер шины PC Card освобождает ресурсы, когда пользователи удаляют PC Card из системы.
Каждая аппаратная платформа имеет уникальные IRQ и доступное пространство В/В. IRQ для встроенных и фиксированных устройств должны отображаться в идентификаторы прерываний ( SYSINTR ) в OAL. IRQ для встроенных и фиксированных устройств должны исключаться из доступных ресурсов. IRQ используемые с шиной PCI обычно являются совместно используемыми.
IRQ и ресурсы пространства В/В являются предопределенными. Ключи реестра HKEY_LOCAL_MACHINE\Drivers\Resources\IRQ и ключи реестра HKEY_LOCAL_MACHINE\Drivers\Resources\IO предоставляют начальное состояние Менеджера ресурсов В/В.
Загрузчик
Загрузчик CE отвечает за загрузку модулей, которые состоят, как из исполнимых файлов, так и динамически подключаемых библиотек (DLL), в виртуальную память, так что они могут выполняться операционной системой. Каждый модуль может иметь несколько связанных с ним флагов в конфигурационном файле Config.bib.
Для каждого модуля можно задать следующие свойства:
- Системный файл
- Скрытый файл
- Сжать ресурсы
- Сжать все
- Не допускать выполнения отладчика
- Пометить модуль как ненадежный
- Игнорировать тип ЦП для каждого модуля отдельно
- Исправлять DLL для правильного выполнения
Загрузчик обрабатывает также несколько выполняемых на месте (XIP) областей, так чтобы отдельные модули можно было обновлять после того, как начальный файл образа операционной системы был записан в устройство.