Семьи и драйверы

Семья I/O Kit является одним или более классами C++, реализующими абстракции программного обеспечения, характерные для всех устройств определенного типа. Набор I/O имеет семьи для протоколов шины (таких как Параллель SCSI, USB и FireWire), для хранения (диск) устройства, для сетевых служб (включая Ethernet), для устройств интерфейса пользователя (таких как мыши, клавиатуры и джойстики), и для узла других устройств.

Драйвер становится элементом семьи посредством наследования; водительский класс является почти всегда подклассом некоторого класса в семье. Будучи элементом семьи, драйвер наследовал структуры данных (переменные экземпляра) и способы поведения, которые характерны для всех элементов семьи. Например, все контроллеры SCSI имеют определенные вещи, которые они должны сделать, такие как сканирование шины SCSI; семья SCSI Parallel определяет и реализует эту функциональность сканирования. Таким образом Вы не должны включать код сканирования в свой новый драйвер контроллера SCSI (если Вы не требуете различной реализации сканирования).

Большая часть разработки Набора I/O включает пишущие определенные классы драйвера, каждый из которых наследовался от суперкласса в семье, обеспечивающей функциональность, которой требует драйвер. Драйвер для контроллера Ethernet, например, наследовался от суперкласса IOEthernetController в семье Network. Объем водительского взаимодействия с его собственной семьей включает функции членства реализации, которые вызывает семья. Это обычно клиентская конфигурация и запросы I/O. Некоторые семьи также определяют объекты и функции для Вашего драйвера для использования. Точный характер этих объектов и функций зависит от семьи Ваши работы драйвера с.

Однако драйвер обычно работает с двумя семьями. В дополнение к семье драйвер является элементом, класс драйвера должен связаться с куском, опубликованным семьей для шины, или протоколировать устройство, присоединен. Кусок (как Драйверы и Куски объясняет подробно) является объектом, определяющим точку доступа и канал передачи для данного протокола. Семья (обычно представляющий шину, такую как PCI или USB) действует как водительский провайдер через кусок, который это создает. Драйвер использует кусок, чтобы присоединить в Реестр I/O и связаться с его устройством. Как пример, драйвер Ethernet PCI использовал бы IOPCIDevice кусок от семьи PCI, чтобы присоединить к и связаться по шине PCI. Водительское основное взаимодействие с куском включает выпуск запросов или команды на любой шине, из которой кусок является клиентом. Драйвер устройства SCSI, например, выпускает блоки команды SCSI и результаты проверок через кусок.

Для больше на семьях, особенно природа и состав суперклассов в семье, посмотрите Классы семьи Набора I/O

Драйверы и куски

Набор I/O поддерживает два широких типа объектов драйвера. Первым является кусок, объект, определяющий точку доступа и канал передачи, обычно для данного протокола, такого как PCI, USB или Ethernet. Второй тип является определенным драйвером для отдельного устройства или службы. Определенный драйвер связывается с аппаратными средствами, через кусок, для выполнения операций I/O. И драйверы и куски в Наборе I/O должны наследоваться от класса IOService.

Драйвер является объектом Набора I/O, управляющим определенной частью аппаратных средств. Драйверы записаны как расширения ядра и обычно устанавливаются в папке Extensions (в /System/Library/Extensions.) См. Обзор Расширения ядра в Руководстве по программированию Ядра для получения дополнительной информации о создании и установке расширений ядра.

Когда драйвер выбран для устройства, но прежде чем он будет загружен в ядро (как расширение ядра), все требуемые семьи — с точки зрения суперклассов и их зависимостей — загружаются для обеспечения общей функциональности для драйвера и других его типа. (Конечно, если эти семьи были уже загружены, этот шаг не необходим.) После того, как все требования для драйвера удовлетворяются, драйвер загружают и инстанцируют как объект. Посмотрите Анатомию Соединения I/O для иллюстрации этого процесса.

Кусок является объектом Набора I/O, представляющим канал передачи для устройства или логической службы и добивающимся доступа к устройству и службе. Например, кусок мог представлять шину, диск, раздел диска, графический адаптер или клавиатуру. Это могло бы помочь думать о куске как о представлении программного обеспечения слота устройства или коннектора. Куски также предоставляют услуги, такие как арбитраж, управление питанием и драйвер, соответствующий (см. Реестр I/O и Каталог I/O).

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

Анатомия Соединения I/O

Многоуровневая архитектура Набора I/O моделирует цепочку соединений между аппаратными шинами и устройствами системы, собирая общую функциональность в классы, с которыми может взаимодействовать Ваш драйвер. Каждый уровень является клиентом уровня ниже его и провайдера служб к уровню выше его. Широкие группировки уровней, определенных семьями I/O Kit, определяют функциональность, характерную для общего типа провайдера I/O, такого как сети или устройства шины PCI.

Рассмотрите рисунок 2-1, иллюстрирующий типичное разделение на уровни клиента и объектов провайдера для основанного на PCI драйвера контроллера Ethernet в семье Network.

Поскольку эта схема показывает, Ваш драйвер обычно соответствует между двумя семьями, наследовавшимися от класса в семье верхнего уровня и использующими службы семьи нижнего уровня. В случае контроллера Ethernet драйвер участвует в штабеле объектов C++, включающих экземпляры классов от семей PCI и сетей:

Другой способ смотреть на штабель объектов драйвера в типичном соединении I/O состоит в том, чтобы рассмотреть штабель с динамической точки зрения. Другими словами, что происходит, когда система OS X обнаруживает новое устройство, присоединенное к нему? Как штабель объектов драйвера создан? Для этого давайте использовать пример диска диска SCSI; общий порядок создания или открытия на рисунке 2-2 слева направо.

Это число иллюстрирует, как драйвер диска SCSI, элемент Семейства систем хранения, подключен к шине PCI. Поскольку каждое конкретное соединение сделано, недавно создаваемый драйвер или кусок также добавляются к Реестру I/O (описанный в Реестре I/O и Каталоге I/O). Цепочка соединений имеет место на нескольких шагах:

1. Драйвер контроллера шины PCI, элемент семьи PCI, обнаруживает устройство PCI и объявляет о его присутствии путем создания куска (IOPCIDevice).

2. Кусок идентифицирует (соответствует) надлежащий драйвер устройства — в этом случае, драйвер контроллера SCSI — и запрашивает, чтобы он был загружен. Загрузка драйвера контроллера SCSI вызывает семью SCSI Parallel и все семьи, что это зависит от, чтобы быть загруженным также. Драйверу контроллера SCSI дают ссылку на IOPCIDevice кусок.

3. Драйвер контроллера SCSI, который является клиентом семьи PCI и провайдером служб помощи семьям Параллели SCSI, сканирует шину SCSI для устройств, которые могли бы быть клиентами этих служб. После нахождения такого устройства (диск), драйвер объявляет о присутствии устройства путем создания куска (IOSCSIDevice).

4. Кусок, путем прохождения через соответствующей процедуры, находит драйвер устройства (дисковый драйвер), который является подходящим для устройства и запрашивает, чтобы был загружен этот драйвер. Загрузка дискового драйвера вызывает Семейство систем хранения и все семьи, что это зависит от, чтобы быть загруженным также. Дисковый драйвер является теперь клиентом семьи SCSI Parallel и участником Семейства систем хранения. Дисковому драйверу дают ссылку на IOSCSIDevice кусок.

Во многих случаях приложения и другие программы «пространства пользователя» могут использовать интерфейсную устройством технологию Набора I/O для дисковых устройств (включая устройства массового хранения), устраняя потребность в резидентном ядром драйвере. Посмотрите Управляющие устройства Извне Ядра для обзора этой сменной технологии.

Функции во время выполнения

Драйверы Набора I/O могут быть загружены и разгружены или активированы и деактивированы в любое время через события, инициируемые программным обеспечением — как тогда, когда сетевые стеки принесены вверх и вниз — и аппаратными средствами — как тогда, когда USB-устройство добавлено к или удалено из шины. Почти все драйверы должны работать в контексте динамично изменяющейся системы. Набор I/O делает это проще путем определения стандартного жизненного цикла для объектов драйвера. Путем реализации маленького набора функций полученных в итоге в Общих Классах Набора I/O, драйвер может корректно обработать дополнение и демонтаж устройств и служб, а также изменений, вызванных системой управления питанием.

Почти все операции I/O требуют той же подготовки в OS X:

• Виртуальная память разбивки на страницы в физическую память

• Проводное соединение памяти вниз, таким образом, это не может быть разбито на страницы во время операций I/O

• Здание рассеивается/собирает списки, описывающие буферы данных, чтобы читать или записать

Набор I/O обеспечивает ряд служебных классов, чтобы помочь драйверам подготовить память к операциям I/O, и создавать рассеиваются/собирают списки, включая классы IOMemoryDescriptor и IOMemoryCursor. Для получения дополнительной информации об этих средствах см., что глава Управляет Данными

Драйверы, работающие в многопоточной системе, должны быть в состоянии защитить свои ресурсы от повторно используемого или параллельного доступа. Набор I/O включает маленький набор классов с этой целью. Объект цикла работы выполняет специализированный поток и управляет механизмом пропускания для эксклюзивного доступа к данным. Другие объекты, названные источниками событий, используют механизм пропускания для сериализации вызовов функции что доступ критические ресурсы, закрывая логический элемент цикла работы прежде, чем вызвать функцию. Для получения дополнительной информации о циклах работы и источниках событий, см., что глава Обрабатывает События

libkern библиотека C++, на которой базируется сам Набор I/O, предоставляет услуги, обычно необходимые драйверам, включая:

• Арифметические и логические операции, которые, как гарантируют, будут атомарными

• Свопинг байта значений между форматами с прямым порядком байтов и с обратным порядком байтов

• Классы для общих наборов данных, таких как строки, массивы и словари

Для получения дополнительной информации о libkern классах посмотрите Классы OS, а также libkern справочную документацию, установленную с пакетом Разработчика OS X.

Ограничения программирования ядра

Код ядра всегда считается резидентным объектом в физической памяти и не может быть разбит на страницы системой виртуальной памяти. Это делает ресурсы ядра намного более дорогими, чем ресурсы прикладной программы. Ваш драйвер должен находиться в ядре если:

• Это берет основные прерывания (когда это должно жить в ядре),

• Его основной клиент находится в ядре; например, драйверы массового хранения, потому что штабели файловой системы находятся в ядре

Драйверы для дисков, сетевых контроллеров, и клавиатур, например, находятся в ядре. Если Ваш драйвер только иногда используется одной программой пространства пользователя за один раз, это должно быть загружено программой и находиться в нем. Драйверы для таких устройств как сканеры и принтеры находятся в программах пространства пользователя, с помощью интерфейсного устройством механизма Набора I/O для передачи с устройствами. Для получения дополнительной информации об интерфейсах устройства посмотрите Управляющие устройства Извне Ядра

Даже если Ваш драйвер находится в ядре, необходимо минимизировать сумму резидентного ядром кода и сумму обработки сделанного тем кодом. Например, специальное применение, управляющее управляемым прерыванием устройством, должно предоставить драйвер, помещающий минимальный код в ядро, должен был обслужить прерывание, сделать доступные данные его клиенту, затем возвратиться. По дополнительным причинам быть осторожными о программировании в ядре, посмотрите, что действительно ли необходимо Программировать в Ядре?

Если Ваш драйвер должен находиться в ядре, необходимо знать о следующих проблемах:

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

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

Резидентные ядром драйверы имеют полный доступ к интерфейсам программирования ядра. Однако из-за их низкого уровня работы, драйверы должны использовать только вызовы Маха и не вызовы BSD. Много частей кода ядра BSD не в настоящее время безопасны для многопоточности или многопроцессорной обработки. В любом случае драйверы редко должны выполнять вызовы Маха непосредственно, поскольку Набор I/O обеспечивает интерфейсы для большей части функциональности уровня ядра, необходимой драйверу.

Классы OS

Набор I/O создается поверх libkern библиотеки C++; то есть корневой суперкласс для I/O, Специфичными для набора классами является IORegistryEntry, наследовавшийся от OSObject libkern. Как Набор I/O, libkern записан в подмножестве C++, подходящего для использования в загружаемых модулях ядра. В частности libkern среда C++ исключает обработку исключений C++ и Информацию о типах во время выполнения (RTTI) средства. Вместо этого базовые классы OS реализуют подходящий эквивалент функции RTTI, среди прочего.

В корне расширенной иерархии класс OSObject, и тесно связанный с этим классом класс OSMetaClass. Все другие классы OS являются классами «помощника» для таких вещей как наборы и другие контейнеры данных. Следующее суммирует роли эти классы игра:

• OSMetaClass реализует информацию о типах во время выполнения (RTTI) механизм, включает определенную степень объектного самоанализа и поддерживает динамическое распределение объектов, полученных из OSObject именем класса.

• Функции APIs OSObject подсчета ссылок (retain и release), управление памятью сохраненных объектов и автоматическое избавление от объектов, когда они больше не необходимы. OSObject также обеспечивает динамическую реализацию по умолчанию init и free методы.

• Контейнеры данных OS являются подклассами OSObject, экземпляры которого инкапсулируют различные типы значений данных (такие как булевские переменные, числа, строки) и реализуют и выполняют итерации по наборам, таким как массивы и словари.

  Контейнеры данных OS приблизительно соответствуют свои дубликаты пространства пользователя, Базовые контейнеры Основы, и на имя и на поведение. Поскольку характеристики OS и Базовых Фундаментальных классов так подобны, система может легко преобразовать Базовый тип Основы в тип OS и наоборот. Например, объект CFArray преобразовывается в OSArray при пересечении границы пользовательского ядра.

Классы OS обычно полезны для всего кода, записанного для ядра, не просто драйверов устройств. Например, реализация расширений ядра сетевые службы или файловые системы может также использовать в своих интересах эти классы. OSObject в частности является существенным общим суперклассом для кода ядра. Для одного модуля ядра (KMOD) к ссылочным объектам, создаваемым другим KMOD, объекты должны в конечном счете произойти из OSObject. Большинство классов Набора I/O предполагает, что раздаваемые объекты получены из OSObject.

При портировании существующего кода C++ на Набор I/O Вы не обязаны использовать классы OS. Но если Вы решите воздержаться от функций, которые эти классы обеспечивают, такие как подсчет ссылок или контейнеры данных, то необходимо будет, вероятно, реализовать их сами.

Для больше на OSObject и классах OSMetaClass, посмотрите libkern Базовые классы в главе “Базовые классы”

Общие Классы Набора I/O

Средняя группа расширенной иерархии классов включает базовые классы Набора IO — IORegistryEntry и IOService — и ряд классов помощника для управления ресурсами, управления данными, и потока и элемента управления вводом. Эта группа классов Набора I/O названа «общей», потому что все классы драйвера устройства могут потенциально использовать их.

Корневым классом иерархии Набора I/O является IORegistryEntry; на основании наследования от IORegistryEntry объект Набора I/O может быть узлом в Реестре I/O и иметь одну или более таблиц свойства (лица драйвера) связанный с ним. IORegistryEntry реализует много опций:

• Это управляет соединением в Реестр через водительское attach и detach точки входа

• Это управляет таблицами свойства, определяющими лица драйвера, использующие объекты OSDictionary

• Это реализует блокировку в Реестре, позволяя обновления Реестру быть сделанным атомарно

IOService является единственным прямым подклассом IORegistryEntry. Почти все суперклассы семьи I/O Kit наследовались, прямо или косвенно, от IOService. Самое главное IOService указывает жизненный цикл драйверов устройств в динамической среде выполнения. Посредством соответствия пар виртуальных функций — такой как init/free, start/stop, и open/close— IOService определяет, как объекты драйвера инициализируют себя, присоединяются в Реестр I/O, выполняют все необходимые выделения, и затем инвертируют эффекты этих действий в надлежащем порядке. Для поддержки его управления жизненными циклами драйвера IOService предоставляет соответствие услуг (помогающий с зондированием, например) и инстанцирует драйверов на основе существования провайдера. Кроме того, IOService включает функции членства, которые полезны в различных целях, включая:

• Уведомление и обмен сообщениями

• Управление питанием

• Память устройства (отображение и доступ)

• Прерывания устройства (регистрация, нерегистрация, включение, порождение, и т.д.)

Для больше на IORegistryEntry и классах IOService, посмотрите Базовые классы Набора I/O в главе “Базовые классы”

Большинство классов помощника Набора I/O имеет несколько функций, связанных со средой выполнения драйверов устройств:

• Реализовывая циклы работы и источники событий (прерывания, таймеры и команды) вместе со связанными блокировками и очередями

• Реализация курсоров памяти и дескрипторов памяти для управления данными, вовлеченными в передачи I/O

Для больше на классах помощника Набора I/O, см., что главы Обрабатывают События и Управляют Данными

Классы семьи Набора I/O

Большинство драйверов является экземплярами подкласса класса в семье I/O Kit; классы семьи, в свою очередь, будьте склонны быть подклассами IOService. Ваш класс драйвера должен быть прямым подклассом самого надлежащего класса семьи для драйвера, который Вы пытаетесь записать. Например, если Вы пишете драйвер контроллера Ethernet, Ваш класс драйвера должен быть подклассом IOEthernetController, не IONetworkController (суперкласс IOEthernetController).

Набор I/O имеет более чем дюжину семей, каждого с его собственным набором классов; эти семьи включают следующее:

• ADB

• ATA и ATAPI

• Аудио

• FireWire

• Графика

• HID (устройства интерфейса пользователя)

• Сеть

• Плата ПК

• PCI и AGP

• SBP-2

• Архитектурная модель SCSI

• Параллель SCSI

• Последовательный

• Запоминающие устройства.

• USB

Apple добавит дополнительные семьи, поскольку они разрабатываются. Если Вы требуете семьи для устройства, и это в настоящее время не поддерживается, можно попытаться писать собственные классы семьи. Однако не предполагайте, что новая семья требуется, если Вы в настоящее время не существуете. Во многих случаях класс IOService предоставляет все услуги, которых требует драйвер; такие драйверы «семьи меньше» могут поддерживать много устройств, которые являются определенными для определенных поставщиков. Для получения дополнительной информации о семьях см. главу семьи Набора I/O и приложение Ссылка семьи Набора I/O

Интерфейсный устройством механизм

Интерфейс устройства является сменным интерфейсом между ядром и процессом в пространстве пользователя. Интерфейс соответствует сменной архитектуре, определенной Базовыми Службами Плагина Основы (CFPlugIn), который, в свою очередь, совместимо с основами Объектной модели компонентов (COM) Microsoft. В модели CFPlugIn действия ядра как сменный узел с его собственным набором четко определенных интерфейсов Набора I/O и платформа Набора I/O обеспечивают ряд плагинов (интерфейсы устройства) для приложений для использования.

Концептуально, интерфейс устройства одновременно покупает и продает границу между пространством пользователя и ядром. Это обрабатывает согласование, аутентификацию и подобные задачи, как будто это был резидентный ядром драйвер. На стороне пространства пользователя это включает связь с приложением (или другая программа) через ее экспортируемые программируемые интерфейсы. На стороне ядра это включает связь с соответствующей семьей I/O Kit через кусок, создаваемый объектом драйвера той семьи. С точки зрения ядра интерфейс устройства, кажется, драйвер и известен как “пользовательский клиент”. С точки зрения приложения интерфейс устройства появляется как ряд функций, которые это может вызвать и через который это может передать данные ядру и получить данные назад от него. Поэтому, на элементном уровне, интерфейс устройства является указателем на таблицу указателей функции (несмотря на то, что он может также включать поля данных). Приложения, как только они получают экземпляр интерфейса устройства, могут вызвать любую из функций интерфейса.

Рисунок 2-4 иллюстрирует архитектуру интерфейса устройства, показывая приложение, получившее доступ к жесткому диску SCSI через интерфейс устройства. Лучше просматривать эту схему как изменение рисунка 2-2, показывающего ряд соединений объектов драйвера, сделанных для резидентного ядром драйвера диска SCSI.

В запуске тот же ряд действий — обнаружения устройств, создания куска, соответствия, загрузки драйвера — происходит от драйвера шины PCI до куска устройства SCSI. Но тогда кусок устройства SCSI соответствует и загружает интерфейс устройства как свой драйвер вместо резидентного ядром драйвера.

Прежде чем приложение может использовать интерфейсный устройством механизм для доступа к устройству, это должно найти устройство. Это выполняет это посредством соответствия вызываемого устройства процесса. В соответствии устройства приложение создает “соответствующий словарь”, указывающий свойства целевого устройства, затем вызывающий функцию Набора I/O, передающую в словаре. Функция ищет Реестр I/O и возвращается, один или несколько соответствующих драйверов возражают, что приложение может тогда использовать для загрузки надлежащего интерфейса устройства. Для больше по этой теме, посмотрите, что Соответствует Устройство

Если Вы разрабатываете пользовательский драйвер, который является не подкласс класса в семье I/O Kit, и Вы хотите, чтобы приложения были в состоянии получить доступ к драйверу, необходимо записать собственный интерфейс устройства. Любой код, связывающийся между пространством пользователя и ядром, должен использовать один или больше следующих средств:

• Системные вызовы BSD

• Мах IPC

• Общая память Маха

Набор I/O использует прежде всего Маха общая память Маха и IPC. Напротив, сети и компоненты файловой системы OS X используют прежде всего системные вызовы BSD.

Файлы устройств POSIX

BSD, центральный компонент среды ядра OS X, экспортирует много программируемых интерфейсов, которые являются соответствующими стандарту POSIX. Эти интерфейсы включают связь с последовательным, хранением и сетевыми устройствами через файлы устройств. В любой основанной на UNIX системе, такой как BSD, файл устройств является специальным файлом, расположенным в /dev это представляет блочное устройство или устройство посимвольного ввода-вывода, такое как терминал, дисковод или принтер. Если Вы знаете имя файла устройств (например, disk0s2 или mt0) Ваше приложение может использовать функции POSIX такой как open, read, write, и close получить доступ и управлять связанным устройством.

Набор I/O динамично создает файлы устройств в /dev поскольку это обнаруживает устройства. Следовательно, набор файлов устройств постоянно изменяется; различные устройства могли бы быть присоединены к файлам устройств в /dev в любой момент, и те же устройства могли бы иметь различные имена файла устройств в разное время. Из-за этого Ваше приложение не может имена файлов твердого кодирующего устройства. Для определенного устройства необходимо получить из Набора I/O путь к его файлу устройств через процедуру, включающую соответствие устройства. Как только у Вас есть путь, можно использовать POSIX APIs для доступа к устройству.

Обратите внимание на то, что можно получить доступ к сетевым службам от пространства пользователя с помощью сокета BSD APIs. Однако необходимо обычно использовать сокеты, только если более высокий уровень, объединяющий APIS В СЕТЬ в средах Углерода и Какао, не предоставляет Вам функции, которых Вы требуете.