Mac OS 9 сравненных

На Mac OS 9, аппаратные средства доступа приложений в пути, полностью отличающемся от способа, которым это сделано на OS X. Различие в подходе в основном вследствие различий в архитектуре, особенно в отношении между приложением и драйвером.

В отличие от OS X, Mac OS 9 не поддерживает неприкосновенный барьер между адресным пространством приложения и адресным пространством ничего, что было бы найдено в ядре OS X. Приложение имеет доступ к адресу любого другого процесса в системе, включая тот из драйвера.

Этот доступ влияет, как вызываются подпрограммы завершения. Структуру позади всего I/O на Mac OS 9 систем вызывают блоком параметра. Блок параметра содержит поля, обычно требуемые для передачи DMA:

• Адрес узла

• Адрес Target

• Направление передачи

• Подпрограмма завершения и связанные данные

Подпрограмма завершения реализована приложением для обработки любых возвращенных результатов. Драйвер поддерживает связанный список блоков параметра как запросы I/O или задания для механизма DMA для выполнения. Когда задание завершается, аппаратные средства инициировали прерывание, запрашивая драйвер вызвать подпрограмму завершения приложения. Код приложения, реализовывая подпрограмму завершения работает во «время прерывания» — т.е. в контексте аппаратного прерывания. Это приводит к большей вероятности, что программная ошибка в подпрограмме завершения может разрушить или подвесить всю систему.

Если бы та же вещь с прерываниями произошла на OS X, то дополнительно были бы издержки пересечения границы пространства пользователя ядра (с ее импликациями производительности), а также риск для системной устойчивости, идущей с экспортом ресурсов ядра к пространству пользователя.

Интерфейсы Устройства семьи Набора I/O

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

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

Посмотрите Нахождение и Доступ к Устройствам в Доступе к Аппаратным средствам Из Приложений для подробного представления процедуры для получения и использования интерфейсов устройства.

Используя POSIX APIs

Для каждого хранения, сети и последовательного устройства Набор I/O динамично создает файл устройств в файловой системе /dev каталог, когда это обнаруживает устройство и находит драйвер для него, или в системе, запускается или как часть его продолжающегося процесса соответствия. Если Ваш драйвер устройства является элементом Хранения Набора I/O, Сети или семей Serial, то Ваши клиенты могут получить доступ к Вашим водительским службам при помощи POSIX подпрограммы I/O. Они могут просто использовать Реестр I/O для обнаружения файла устройств, связанного с устройством средства управления драйвером. Затем с тем файлом устройств в качестве параметра, они вызывают POSIX функции I/O, чтобы открыть и закрыть устройство и читать и данные записи в него.

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

Доступ к свойствам устройства

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

Все объекты драйвера в ядре происходят из IOService, который является поочередно подклассом класса IORegistryEntry. Методы IORegistryEntry позволяют коду в ядре искать Реестр I/O определенные записи и получить и установить свойства тех записей. Дополнительный набор функций (определенный в IOKitLib.h) существуйте в платформе Набора I/O. Приложения могут использовать функции, чтобы выбрать данные, хранившие как свойства объекта драйвера или отправить данные в объект драйвера.

Этот устанавливающий свойство механизм подходит для ситуаций, где следующие условия являются истиной:

• Драйвер не должен выделять постоянные ресурсы для завершения транзакции.

• Приложение передает — копией — ограниченный объем данных (менее чем страница)

  С устанавливающим свойство механизмом приложение может передать произвольные объемы данных ссылкой (т.е. с помощью указателей).

• Данные не отправили причинам изменения в состоянии драйвера или результатов в единственном, постоянном изменении состояния.

• Вы управляете драйвером в ядре (и таким образом может реализовать setProperties метод, описанный ниже).

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

Общая процедура для отправки данных от приложения до объекта драйвера как свойство запускается с установления соединения с драйвером. Процедура для этого, описанного в Основном Соединении и Процедуре I/O, состоит из трех шагов:

1. Получение ведущего порта Набора I/O

2. Получение экземпляра драйвера

3. Создание соединения

Как только у Вас есть соединение, сделайте следующие шаги:

1. Вызовите IOConnectSetCFProperties функция, передающая в соединении и Базовом контейнерном объекте Основы, таком как CFDictionary.

   Базовый объект Основы содержит данные, которые Вы хотите передать драйверу. Обратите внимание на то, что можно вызвать IOConnectSetCFProperty вместо этого, если Вы хотите передать только сингл, объект Основы Ядра типа значения, такой как CFString или CFNumber и что ключ значения. Оба вызова функции вызывают вызов IORegistryEntry::setProperties метод в драйвере.

2. В драйвере реализуйте setProperties метод.

   Прежде чем это вызовет этот метод, Набор I/O преобразовывает Базовый объект Основы, переданный в пользовательским процессом к соответствующему libkern контейнерному объекту (такому как OSDictionary). В его реализации этого метода объект драйвера извлекает данные из libkern контейнерного объекта и делает с ним, что ожидается.

Базовый объект Основы, переданный в пользовательским процессом, должен, конечно, иметь libkern эквивалент. Таблица 4-1 показывает допустимые Базовые типы Основы и их соответствующие объекты libkern.

Следующий пример (Перечисление 4-1) показывает, как семья Serial Набора I/O использует механизм установки свойства Реестра I/O, чтобы позволить пользовательскому процессу сделать поток драйвера неактивным, пока последовательный порт не свободен использовать (когда существуют устройства, такие как модем и факс, конкурирующий за порт).

Перечисление 4-1  , Управляющее использованием последовательного устройства setProperties

IOReturn IOSerialBSDClient::

setOneProperty(const OSSymbol *key, OSObject *value)

{

    if (key == gIOTTYWaitForIdleKey) {

        int error = waitForIdle();

        if (ENXIO == error)

            return kIOReturnOffline;

        else if (error)

            return kIOReturnAborted;

        else

            return kIOReturnSuccess;

    }

    return kIOReturnUnsupported;

}

IOReturn IOSerialBSDClient::

setProperties(OSObject *properties)

{

    IOReturn res = kIOReturnBadArgument;

    if (OSDynamicCast(OSString, properties)) {

        const OSSymbol *propSym =

            OSSymbol::withString((OSString *) properties);

        res = setOneProperty(propSym, 0);

        propSym->release();

    }

    else if (OSDynamicCast(OSDictionary, properties)) {

        const OSDictionary *dict = (const OSDictionary *) properties;

        OSCollectionIterator *keysIter;

        const OSSymbol *key;

        keysIter = OSCollectionIterator::withCollection(dict);

        if (!keysIter) {

            res = kIOReturnNoMemory;

            goto bail;

        }

        while ( (key = (const OSSymbol *) keysIter->getNextObject()) ) {

            res = setOneProperty(key, dict->getObject(key));

            if (res)

                break;

        }

        keysIter->release();

    }

bail:

    return res;

}

Пользовательские пользовательские клиенты

Если Вы не можете сделать свои аппаратные средства должным образом доступными для приложений с помощью стандартных интерфейсов устройства Набора I/O, POSIX APIs или свойства I/O Registry, то необходимо будет, вероятно, записать пользовательскому пользовательскому клиенту. Чтобы сделать этот вывод, необходимо было сначала ответить «нет» на следующие вопросы:

• Если Ваше устройство элемент семьи I/O Kit, та семья обеспечивает интерфейс устройства?

• Действительно ли Ваше устройство является сериалом, сетями или устройством хранения?

• Действительно ли свойства I/O Registry достаточны для потребностей приложения? (Если необходимо переместить огромные объемы данных, или если Вы не управляете кодом драйвера, тогда они, вероятно, не.)

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

Типы транспорта пользователя-клиента

Набор I/O APIs включает несколько различных типов транспорта через границу между ядром и пространством пользователя:

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

• Совместное использование памяти: Это - форма памяти, отображающейся, в котором или больше страниц памяти отображаются в адресное пространство двух задач — в этом случае, драйвер и порядок подачи заявки. Или процесс может тогда получить доступ или изменить данные, хранившие на тех поделившихся страницах. Механизм пользователя-клиента для общей памяти использует объекты IOMemoryDescriptor на стороне ядра и буферных указателях vm_address_t на стороне пользователя для отображения аппаратных регистров на пространство пользователя. Этот метод передачи данных предназначается для аппаратных средств, которые не основаны на DMA и идеальны для перемещения больших объемов данных между аппаратными средствами и приложением. Пользовательские процессы могут также отобразить свою память в адресное пространство ядра.

• Отправка уведомлений: Этот механизм передает порты уведомлений в и из ядра для отправки уведомлений между ядром и пользовательскими процессами. Эти методы используются в асинхронной передаче данных.

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

Синхронный по сравнению с асинхронной передачей данных

Два стиля передачи невведенных данных возможны с пользователем-клиентом Набора I/O APIs: Синхронный и асинхронный. У каждого есть его сильные места и недостатки, и каждый более подходит для определенных характеристик аппаратных средств и пространства пользователя API. Несмотря на то, что асинхронная модель I/O несколько сопоставима с путем Mac OS 9 аппаратных средств доступа приложений, это отличается в некотором отношении. Старшим значащим из этих различий является аспект архитектуры, совместно использованной с синхронной моделью: В OS X клиент обеспечивает поток, на котором вызывают подпрограммы завершения I/O, но ядро управляет потоком. Подпрограммы завершения I/O выполняются вне контекста ядра.

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

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

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

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

Пользовательский процесс должен создать и управлять дополнительными потоками в этой модели с помощью некоторого средства пользовательского уровня, такими как BSD pthreads. Эта необходимость указывает на основной недостаток асинхронной модели: проблема управления потоком в многопоточной среде. Это - что-то, что трудно сделать правильно. Другая проблема с асинхронным I/O связана с производительностью; с этим типом I/O существует два распространения в прямом и обратном направлениях пространства пользователя ядра на I/O. Один способ смягчить эту проблему состоит в том, чтобы обработать уведомления завершения в пакетном режиме и иметь уведомления потоки процессы несколько из них сразу. Для асинхронного подхода Вы также могли бы рассмотреть базирование потока I/O клиента на объекте цикла выполнения (CFRunLoop); этот объект является превосходным мультиплексором, позволяя Вам иметь различные источники событий пространства пользователя.

Таким образом, какая модель для I/O является лучше, синхронной или асинхронной? Как со многими аспектами проекта, ответ является определенным, “это зависит”. Это зависит от любого кода унаследованного приложения, с которым Вы работаете, это зависит от изощренности Вашего программирования потока, и это зависит от уровня I/O. Когда число операций в секунду I/O ограничивается (хорошо под 1 000 в секунду), асинхронный подход хорош. Иначе, рассмотрите синхронную модель I/O, пользующуюся лучшим преимуществом архитектуры OS X.

Диапазон доступности

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

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

Так скажем, Вы решили поместить свое соединение и код I/O в интерфейс устройства; теперь необходимо решить то, что формируется, этот интерфейс устройства должен взять. Соединение и код I/O должны вызвать функции, определяемые в платформе Набора I/O, содержащей Мужественную динамическую совместно используемую библиотеку; следовательно, все интерфейсы устройства должны быть созданы как исполняемый код на основе Мужественного формата объектных файлов. Интерфейс устройства может быть упакован как пакет, содержащий динамическую совместно используемую библиотеку или как плагин. Другими словами, общий выбор API между CFBundle (или NSBundle Какао) или CFPlugIn.

Решение между пакетом и плагином обусловлено природой приложений, которые будут клиентами Вашего пользовательского клиента. Если существует хороший шанс, что основанные на CFM приложения захотят получить доступ к Вашему драйверу, необходимо использовать APIs CFBundle, потому что CFBundle обеспечивает возможности перекрестной архитектуры. Если Вы требуете более мощной абстракции для доступности устройства, и клиенты приложения вряд ли будут основаны на CFM, можно использовать CFPlugIn APIs. Как исторический очерк, семьи Набора I/O используют CFPlugIns для своих интерфейсов устройства, потому что эти типы плагинов обеспечивают больший диапазон доступности, позволяя сторонним разработчикам создать подобные драйверу модули в пространстве пользователя.

Если только одно приложение будет клиентом Вашего пользовательского пользовательского клиента, но то приложение основывается на объектном коде CFM-PEF, необходимо создать Мужественный пакет (использующий CFBundle или APIs NSBundle) как интерфейс устройства для приложения.

В большинстве случаев можно безопасно выбрать CFBundle (или NSBundle) для интерфейса устройства. В дополнение к их возможности вызова перекрестной архитектуры они связываются, APIs упрощает создавать интерфейс устройства.

Проект унаследованных приложений

Основным фактором в проекте Вашего пользовательского клиента является API приложений, в настоящее время получающих доступ к аппаратным средствам на других платформах, таких как Mac OS 9 или Windows. Разработчики, портирующие эти приложения на OS X, будут (понятно) обеспокоены тем, как трудно это должно будет заставить их приложения работать с пользовательским пользовательским клиентом. Они, вероятно, захотят отодвинуться такое количество связанного с аппаратными средствами кода своего приложения, как они могут к OS X, но это может не быть просто сделать.

Например, если приложение, API основывается на инициированных прерыванием асинхронных обратных вызовах, такой как на Mac OS 9, что API не подходит для OS X, где поток основного прерывания должен остаться в ядре. Несмотря на то, что Набор I/O действительно имеет APIs для асинхронного I/O, этот APIs значительно отличается, чем те в Mac OS 9. Кроме того, предпочтительный подход для OS X должен использовать синхронные вызовы. Таким образом, это могло бы быть хорошей возможностью для разработчика приложений обновить его архитектуру аппаратного API.

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

Оборудование.

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

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

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

Учитывая эти требования, можно проявить один из четырех подходов в проекте пользовательского клиента. Если к Вашему аппаратному управлению памятью получают доступ через PIO, первые два являются опциями:

• Полное управление памятью PIO. Поскольку Вы не требуете прерываний или доступа физической памяти, можно отобразить аппаратные регистры в адресное пространство приложения и управлять устройством оттуда.

• Управление памятью PIO с прерываниями. Если аппаратные средства PIO используют прерывания, необходимо делать попытку измененной версии предыдущего подхода. Можно отобразить регистры на пространство пользователя, но пользовательский процесс должен обеспечить поток для пересылки уведомлений прерывания. Недостаток этого подхода - то, что управление памятью не настолько хорошо; это подходит только для низкой пропускной способности.

Посмотрите Отображающиеся Регистры Устройства и RAM В Пространство пользователя для получения дополнительной информации об этих двух отображающих память подходах.

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

• Основанный на функции пользовательский клиент. Этот вид пользовательского клиента определяет дополнительные наборы функций с обеих сторон границы пространства пользователя ядра (например, WriteBlockToDevice или ScanImage). Вызывание одной функции на стороне пользователя приводит к вызову функции на стороне ядра. Если набор функций не является маленьким, Вы не должны проявлять этот подход, потому что это поместило бы слишком много кода в ядро.

• Основанные на регистре файлы задачи. Файл задачи является массивом, обрабатывающим ряд в пакетном режиме команд для получения и установки значений регистра и адресов. Пользовательский клиент реализует только четыре «примитивных» функции, воздействующие на содержание файла задачи. Файлы задачи полностью объяснены в следующем разделе, Файлах Задачи.

Когда у Вас есть аппаратные средства DMA, пользовательские клиенты, использующие основанные на регистре файлы задачи, являются рекомендуемым подходом к проектированию. Посмотрите Передающие Невведенные Данные Синхронно для примеров.

Файлы задачи

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

На стороне ядра все, в чем Вы нуждаетесь, является четырьмя «примитивными» методами, выполняющими основные операции, возможные с аппаратными регистрами:

• Получите значение в регистре x

• Регистр набора x для оценки y

• Получите адрес в регистре x

• Регистр набора x для обращения y

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

Посмотрите Передающие Невведенные Данные Синхронно для примера файлов задачи.

Сценарий проекта

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

Как пример, скажите, что у Вас есть плата PCI с возможностями цифровой обработки сигналов (DSP). Нет никакой семьи I/O Kit для устройств этого типа, таким образом, Вы знаете, что не может быть никакого интерфейса устройства семьи, который можно использовать. Теперь, скажем, карта использует и управление памятью DMA и прерывания, таким образом, должен быть код в ядре для обработки этих вещей; следовательно, драйвер должен быть записан, чтобы сделать это, и вероятно пользовательский клиент. Поскольку большая сумма данных DSP должна быть перемещена в и от карты, свойства I/O Registry не являются верным решением. Таким образом пользовательский пользовательский клиент необходим.

На другой платформе существует код пространства пользователя, вручающий от обработки задач к DSP. Этот код работает и над Mac OS 9 и над Windows. К счастью, существующий API абсолютно синхронен; может быть только один выдающийся запрос на поток. Этот аспект API делает его логическим шагом для адаптации кода, чтобы реализовать синхронную передачу данных в пользовательском клиенте и отобразить память карты в адресное пространство приложения для передач DMA.

Основное Соединение и Процедура I/O

Необходимо выполнить определенные задачи в коде стороны пользователя для соединения, создаете ли Вы библиотеку или включаете соединение и функциональность I/O в единственном клиенте приложения. Этот раздел суммирует те задачи, все из которых включают призывающий функции, определяемые IOKitLib.h.

typedef struct MySampleStruct

{

    UInt16 int16;

    UInt32 int32;

} MySampleStruct;

enum

{

    kMyUserClientOpen,

    kMyUserClientClose,

    kMyScalarIStructImethod,

    kMyScalarIStructOmethod,

    kMyScalarIScalarOmethod,

    kMyStructIStructOmethod,

    kNumberOfMethods

};

kernResult = IOMasterPort(MACH_PORT_NULL, &masterPort);

classToMatch = IOServiceMatching(kMyDriversIOKitClassName);

    kernResult = IOServiceGetMatchingServices(masterPort, classToMatch, &iterator);

    if (kernResult != KERN_SUCCESS)

    {

        printf("IOServiceGetMatchingServices returned %d\n\n", kernResult);

        return 0;

    }

    serviceObject = IOIteratorNext(iterator);

    IOObjectRelease(iterator);

    // ...

    kern_return_t   kernResult;

    mach_port_t     masterPort;

    io_service_t    serviceObject;

    io_connect_t    dataPort;

    io_iterator_t   iterator;

    CFDictionaryRef classToMatch;

    // ...

    kernResult = IOMasterPort(MACH_PORT_NULL, &masterPort);

    if (kernResult != KERN_SUCCESS)

    {

        printf( "IOMasterPort returned %d\n", kernResult);

        return 0;

    }

    classToMatch = IOServiceMatching(kMyDriversIOKitClassName);

    if (classToMatch == NULL)

    {

        printf( "IOServiceMatching returned a NULL dictionary.\n");

        return 0;

    }

    kernResult = IOServiceGetMatchingServices(masterPort, classToMatch,

                                            &iterator);

    if (kernResult != KERN_SUCCESS)

    {

        printf("IOServiceGetMatchingServices returned %d\n\n", kernResult);

        return 0;

    }

    serviceObject = IOIteratorNext(iterator);

    IOObjectRelease(iterator);

    if (serviceObject != NULL)

    {

        kernResult = IOServiceOpen(serviceObject, mach_task_self(), 0,

                                    &dataPort);

        IOObjectRelease(serviceObject);

        if (kernResult != KERN_SUCCESS)

        {

            printf("IOServiceOpen returned %d\n", kernResult);

            return 0;

        }

    // ...

enum{    kMyUserClientOpen,    kMyUserClientClose,    // ...};

// ...

    kern_return_t   kernResult;

// ...

    kernResult = IOConnectMethodScalarIScalarO(dataPort, kMyUserClientOpen,

                                                0, 0);

    if (kernResult != KERN_SUCCESS)

        {

            IOServiceClose(dataPort);

            return kernResult;

        }

    // ...

kern_return_t

IOConnectMethodScalarIStructureO(

    io_connect_t    connect,

    unsigned int    index,

    IOItemCount     scalarInputCount,

    IOByteCount *   structureSize,

    ... );

kern_return_t

MyScalarIStructureOExample(io_connect_t dataPort)

{

    MySampleStruct  sampleStruct;

    int             sampleNumber1 = 154;    // This number is random.

    int             sampleNumber2 = 863;    // This number is random.

    IOByteCount     structSize = sizeof(MySampleStruct);

    kern_return_t   kernResult;

    kernResult = IOConnectMethodScalarIStructureO(dataPort,

                        kMyScalarIStructOmethod, // method index

                        2,  // number of scalar input values

                        &structSize, // size of ouput struct

                        sampleNumber1,  // scalar input value

                        sampleNumber2,  // another scalar input value

                        &sampleStruct   // pointer to output struct

                        );

    if (kernResult == KERN_SUCCESS)

    {

        printf("kMyScalarIStructOmethod was successful.\n");

        printf("int16 = %d, int32 = %d\n\n", sampleStruct.int16,

                (int)sampleStruct.int32);

        fflush(stdout);

    }

    return kernResult;

}

kernResult = IOConnectMethodScalarIScalarO(dataPort, kMyUserClientClose, 0,

                                            0);

Аспекты проекта для интерфейсов устройства

При разработке интерфейса устройства попытайтесь переместить как можно больше кода и логики в него. Только поместите код в ядро, которое абсолютно должно быть там. Когда проект основывается на подходе файла задачи, код пользовательского интерфейса в ядре должен быть плотно связан с аппаратными средствами, особенно.

Одна причина этого была подчеркнута прежде: Код в ядре может быть дренажом на производительности и источнике нестабильности. Но другая причина должна быть так же важна для разработчиков. Код пространства пользователя намного проще отладить, чем код ядра.

Основы проекта пользователя-клиента

Пользовательский клиент является, прежде всего, объектом драйвера. Это в «вершине» штабеля драйвера между его провайдером (драйвер) и его клиентом (пользовательский процесс). Как объект драйвера, это должно участвовать в жизненный цикл драйвера путем реализации надлежащих методов: start, open, и т.д. (см. Основные принципы IOKit для описания жизненного цикла драйвера). Это должно связаться с его провайдером в надлежащие моменты. И это должно также поддержать соединение со своим клиентом (пользовательский процесс) вместе с любым состоянием, связанным с тем соединением; дополнительно, когда клиент уходит, это - пользовательская ответственность клиента очистить.

Учитывая тесную связь между драйвером и его пользовательским клиентом, рекомендуется включать исходные файлы для пользовательского клиента в проекте для драйвера. Если Вы хотите Набор I/O, в ответ на IOServiceOpen быть вызванным в пространстве пользователя, для автоматического выделения, запускается, и присоединяет экземпляр подкласса пользователя-клиента, указывает IOUserClientClass свойство в информационном списке свойств Вашего драйвера. Значение свойства должно быть полным именем класса Вашего пользовательского клиента. Также Ваш класс драйвера может реализовать метод IOService newUserClient для создания присоедините и запустите экземпляр подкласса IOUserClient.

В пользовательском заголовочном файле клиента объявите методы жизненного цикла, что Вы являетесь переопределяющими; они могут включать start, message, terminate, и finalize. Эти сообщения распространены, штабель драйвера, от драйвера возражают самый близкий к аппаратным средствам пользовательскому клиенту. Также объявите open и close методы; сообщения, вызывающие эти методы, распространены в противоположном направлении и порождаются приложением или самим интерфейсом устройства. open метод, в котором пользовательский клиент открывает его провайдера, особенно важен как место, где осуществляется монопольный доступ к устройствам. Для больше на пользовательском клиенте open и close методы, посмотрите Монопольный Доступ к устройствам и открыть Method; для роли приложения в этом посмотрите, Открывают User Client.

Существует одна определенная вещь отметить о start метод. В Вашей реализации этого метода проверьте, что переданным - в объекте провайдера является экземпляр Вашего водительского класса (использование OSDynamicCast) и присвойте его переменной экземпляра. Ваш пользовательский клиент должен отправить несколько сообщений в его провайдера в течение времени, оно загружается, таким образом, полезно сохранить ссылку на провайдера удобной.

Необходимо будет также объявить и реализовать некоторые методы, определенные для инициализации пользовательского клиента и завершения клиентского процесса. Следующие разделы обсуждают эти методы.

bool

com_apple_dts_SimpleUserClient::initWithTask(task_t owningTask,

                                    void *security_id , UInt32 type)

{

    IOLog("SimpleUserClient::initWithTask()\n");

    if (!super::initWithTask(owningTask, security_id , type))

        return false;

    if (!owningTask)

    return false;

    fTask = owningTask;

    fProvider = NULL;

    fDead = false;

    return true;

}

 static const IOExternalMethod sMethods[kNumberOfMethods] =

    {

        {   // kMyUserClientOpen

            NULL,

            (IOMethod) &com_apple_dts_SimpleUserClient::open,

            kIOUCScalarIScalarO,

            0,

            0

        },

        {   // kMyUserClientClose

            NULL,

            (IOMethod) &com_apple_dts_SimpleUserClient::close,

            kIOUCScalarIScalarO,

            0,

            0

        },

      // ...

   );

IOReturn

com_apple_dts_SimpleUserClient::open(void)

{

    if (isInactive())

        return kIOReturnNotAttached;

    if (!fProvider->open(this))

        return kIOReturnExclusiveAccess;

    return kIOReturnSuccess;

}

IOReturn

com_apple_dts_SimpleUserClient::close(void)

{

    IOLog("SimpleUserClient::close()\n");

    if (!fProvider)

        return kIOReturnNotAttached;

    if (fProvider->isOpen(this))

        fProvider->close(this);

    return kIOReturnSuccess;

}

IOReturn

com_apple_dts_SimpleUserClient::clientClose(void)

{

    // release my hold on my parent (if I have one).

    close();

    terminate();

    if (fTask)

    fTask = NULL;

    fProvider = NULL;

    // DON'T call super::clientClose, which just returns notSupported

    return kIOReturnSuccess;

}

IOReturn

com_apple_dts_SimpleUserClient::clientDied(void)

{

    IOReturn ret = kIOReturnSuccess;

    IOLog("SimpleUserClient::clientDied()\n");

    // do any special clean up here

    ret = super::clientDied();

    return ret;

}

Передача невведенных данных синхронно

Основной механизм IOUserClient для передающих данных между драйвером и приложением, в его ядре, массиве указателей на функции членства, реализованные в драйвере или, в некоторых случаях, пользовательский клиент. Пользовательский клиент и пользовательский процесс согласуют ряд констант, действующих как индексы в массив. Когда пользовательский процесс звонит, чтобы считать или записать некоторые данные, он передает этот индекс вместе с некоторыми параметрами ввода и вывода. Используя индекс, пользовательский клиент находит требуемый метод и вызывает его, проводя обязательные параметры.

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

typedef IOReturn (IOService::*IOMethod)(void * p1, void * p2, void * p3,

                                void * p4, void * p5, void * p6 );

static const IOExternalMethod sMethods[kNumberOfMethods] =

{

    {   // kMyUserClientOpen

        NULL,                   // Target determined at runtime.

        (IOMethod) &com_apple_dts_SimpleUserClient::open,

        kIOUCScalarIScalarO,    // Scalar Input, Scalar Output.

        0,                      // No scalar input values.

        0                       // No scalar output values.

    },

    {   // kMyUserClientClose

        NULL,                   // Target determined at runtime.

        (IOMethod) &com_apple_dts_SimpleUserClient::close,

        kIOUCScalarIScalarO,    // Scalar Input, Scalar Output.

        0,                      // No scalar input values.

        0                       // No scalar output values.

    },

    {   // kMyScalarIStructImethod

        NULL,                   // Target determined at runtime.

        (IOMethod) &com_apple_dts_SimpleDriver::method1,

        kIOUCScalarIStructI,    // Scalar Input, Struct Input.

        1,                      // One scalar input value.

        sizeof(MySampleStruct)  // The size of the input struct.

    },

    {   // kMyScalarIStructOmethod

        NULL,                   // Target determined at runtime.

        (IOMethod) &com_apple_dts_SimpleDriver::method2,

        kIOUCScalarIStructO,    // Scalar Input, Struct Output.

        2,                      // Two scalar input values.

        sizeof(MySampleStruct)  // The size of the output struct.

    },

    {   // kMyScalarIScalarOmethod

        NULL,                   // Target determined at runtime.

        (IOMethod) &com_apple_dts_SimpleDriver::method3,

        kIOUCScalarIScalarO,    // Scalar Input, Scalar Output.

        2,                      // Two scalar input values.

        1                       // One scalar output value.

    },

    {   // kMyStructIStructOmethod

        NULL,                   // Target determined at runtime.

        (IOMethod) &com_apple_dts_SimpleDriver::method4,

        kIOUCStructIStructO,    // Struct Input, Struct Output.

        sizeof(MySampleStruct), // The size of the input struct.

        sizeof(MySampleStruct)  // The size of the output struct.

    },

};

Реализация getTargetAndMethodForIndex

Все подклассы IOUserClient, использующих механизм невведенных данных для передачи данных между приложением и драйвером, должны реализовать getTargetAndMethodForIndex метод (или, для асинхронной поставки, getAsyncTargetAndMethodForIndex). Типичная реализация getTargetAndMethodForIndex должен сделать две вещи:

• Возвратите непосредственно указатель на надлежащее IOExternalMethod структура, идентифицирующая метод для вызова.

• Возвратите ссылку на объект, реализующий метод (цель).

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

Перечисление 4-13  реализовывая getTargetAndMethodForIndex метод

IOExternalMethod *

com_apple_dts_SimpleUserClient::getTargetAndMethodForIndex(IOService **

target, UInt32 index)

{

// Make sure IOExternalMethod method table has been constructed

// and that the index of the method to call exists

if (index < (UInt32)kNumberOfMethods)

{

if (index == kMyUserClientOpen || index == kMyUserClientClose)

{

// These methods exist in SimpleUserClient

*target = this;

}

else

{

// These methods exist in SimpleDriver

*target = fProvider;

}

return (IOExternalMethod *) &sMethods[index];

}

return NULL;

};

Передача невведенных данных асинхронно

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

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

Можно выполнить то же асинхронное поведение с помощью цикла выполнения приложения (CFRunLoop). Основной поток каждого приложения имеет объект цикла выполнения, имеющий, получают права на наборе порта Маха, на котором все источники событий, подходящие для приложения (события от нажатия мыши, события дисплея, уведомления пространства пользователя, и т.д.), имеют, отправляют права. Работая в жестком цикле, CFRunLoop проверяет, имеет ли какой-либо из источников событий в его наборе порта Маха незаконченные события и, если они делают, диспетчеризирует событие намеченному месту назначения.

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

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

Отображение регистров устройства и RAM в пространство пользователя

Если Ваш драйвер имеет аппаратные средства с полным управлением памятью PIO, Ваш пользовательский клиент может отобразить аппаратные регистры в адресное пространство пользовательского процесса. В этом случае пользовательский процесс не требует доступа к физическим адресам. Однако, если аппаратные средства PIO действительно потребуют использования прерываний, то у Вас будет к фактору это требование в Ваш код. Это всегда возможно, даже с аппаратными средствами DMA, для публикации устройства RAM к пространству пользователя.

Пользовательский процесс подает заявку для расширенной памяти путем вызова IOConnectMapMemory, передавая в, среди других параметров, указателя на (что станет), расширенная память в ее собственном адресном пространстве. IOConnectMapMemory результаты вызова в вызове clientMemoryForType метод в пользовательском клиенте. В его реализации этого метода пользовательский клиент возвращает объект IOMemoryDescriptor, который он создал в open или start метод, поддерживающий отображение на аппаратные регистры. Пользовательский процесс получает назад это отображение с точки зрения типов виртуальной памяти vm_address_t и vm_size_t. Это теперь свободно читать из и записать в аппаратные регистры.

Вместо того, чтобы создать объект IOMemoryDescriptor, пользовательский клиент мог (в большинстве случаев) просто создать объект IODeviceMemory куском его провайдера. Затем в clientMemoryForType метод, это возвращает указатель на объект IODeviceMemory. (IODeviceMemory является подклассом IOMemoryDescriptor.), Если это делает это, это должно гарантировать, что флаг без кэширований включен (осуществлением операции ИЛИ надлежащий флаг в IOOptionBits параметр). Кусок обеспечивающего драйвера использует объект IODeviceMemory отобразить регистры физического адресного пространства устройства PCI к виртуальному адресному пространству ядра. Через этот объект это может достигнуть адресное пространство ядра, которое делает большинство драйверов, когда они хотят говорить с аппаратными регистрами. Возврат IODeviceMemory провайдера возражает в clientMemoryForType метод также, как Вы публикуете (PCI) устройство RAM к пространству пользователя.

Удостоверьтесь, что Вы сохраняете IODeviceMemory или любой другой объект IOMemoryDescriptor в Вашей реализации clientMemoryForType таким образом, ссылка на него может быть возвращена к вызывающей стороне.

Если пользовательский клиент создает объект IOMemoryDescriptor в open метод, это должно выпустить объект в close метод; если пользовательский клиент создает объект IOMemoryDescriptor в start метод, это должно выпустить объект в stop метод. Если пользовательский клиент передает объект IODeviceMemory, создаваемый его провайдером, он не должен выпускать его вообще (провайдер должен выпустить его соответственно). К концу I/O интерфейс устройства или приложение должны вызвать IOConnectUnmapMemory.

Например, реализации IOConnectMapMemory и clientMemoryForType, см. Перечисление 4-18 и Перечисление 4-24, соответственно.