Обработка прерываний в наборе I/O

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

Два типа событий инициировали прерывание:

• Основанные на команде события, такие как входящие сетевые пакеты и чтения носителей

• Асинхронные события, такие как нажатия клавиатуры

Когда прерывание происходит, определенная линия прерывания установлена и, как только прерванный поток заканчивает текущую команду, ответвления управления к контроллеру прерываний, зарегистрированному в Эксперте по Платформе. Когда контроллер прерываний получает прерывание, его поток становится потоком прямого (основного) прерывания. Существует обычно только одно прямое прерывание в системе в любой момент, и контекст прямого прерывания имеет самый высокий приоритет в системе. Следующий список указывает относительные приоритеты потоков в системе:

1. Прямое прерывание

2. Таймеры и страница

3. Реальное время (мультимедиа)

4. Косвенные прерывания (драйверы)

5. Менеджер окон

6. Пользовательские потоки (включая запросы I/O)

Из-за его чрезвычайно высокого приоритета контекст прямого прерывания несет ответственность за проект вручить от прерывания потокам более низкого приоритета как можно скорее. Контроллер прерываний должен декодировать, почему прерывание было взято, присвойте его надлежащему объекту драйвера и возврату.

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

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

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

Цикл работы может иметь несколько IOInterruptEventSource объекты, присоединенные к нему. Порядок, в котором эти объекты добавляются к циклу работы (через IOWorkLoop addEventSource функция), определяет общий порядок, в котором обрабатываются прерывания из других источников.

Рисунок 7-2 иллюстрирует некоторые из этих понятий. Это показывает события, происходящие из других источников, поставляемых соответствующим объектам источника события, «присоединенным» к циклу работы. Как с любым объектом источника события, каждый источник события прерывания действует как очередь для событий того типа; когда существует событие в очереди, объект сигнализирует цикл работы, что это имеет работу для него. Цикл работы (т.е. специализированный поток) пробуждает и запрашивает каждый установленный источник события поочередно. Если источник события имеет работу, цикл работы выполняет подпрограмму завершения для события (в этом случае, прерывание) в его собственном защищенном потоке. Предыдущее сообщение — клиентский поток, выполняющий код источника события — блокируется, пока подпрограмма не заканчивает обрабатывать событие. Тогда цикл работы перемещается в следующий источник события прерывания и, если существует работа, выполняет подпрограмму завершения для того прерывания в его защищенном контексте. Когда больше нет работы, чтобы сделать, сны цикла работы.

Помните, что порядок, в котором Вы добавляете источники событий прерывания к циклу работы, определяет порядок обработки для определенных событий прерывания.

Установка обработчика прерываний, присоединенного к циклу работы

Драйвер обычно создает объект источника события прерывания — обычно IOInterruptEventSource или IOFilterInterruptEventSource класс — в start функция путем вызова метода создания фабрики для класса (например, interruptEventSource). Этот метод указывает сам драйвер как цель и идентифицирует функцию членства действия (соответствующий Action введите определенный для класса источника события) быть вызванным как подпрограмма завершения для источника события. Метод фабрики также связывает драйвер с провайдером, имеющим дело со средством аппаратного прерывания (обычно кусок, такой как IOPCIDevice). Драйвер тогда регистрирует источник события в цикле работы через IOWorkLoop addEventSource функция.

Перечисление 7-2 обеспечивает пример для установки источника события прерывания.

Перечисление 7-2  , Добавляющее источник события прерывания к циклу работы

myWorkLoop = (IOWorkLoop *)getWorkLoop();

interruptSource = IOInterruptEventSource::interruptEventSource(this,

    (IOInterruptEventAction)&MyDriver::interruptOccurred,

    provider);

if (!interruptSource) {

    IOLog("%s: Failed to create interrupt event source!\n", getName());

    // Handle error (typically by returning a failure result).

    }

if (myWorkLoop->addEventSource(interruptSource) != kIOReturnSuccess) {

    IOLog("%s: Failed to add interrupt event source to work loop!\n",

        getName());

    // Handle error (typically by returning a failure result).

}

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

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

Вы уничтожаете источник события прерывания в водительской функции деактивации (обычно stop). Перед выпуском IOInterruptEventSource объект, необходимо отключить его и затем удалить его из цикла работы. Перечисление 7-3 дает пример того, как сделать это.

Перечисление 7-3  , избавляющееся IOInterruptEventSource объект

if (interruptSource) {

    interruptSource->disable();

    myWorkLoop->removeEventSource(interruptSource);

    interruptSource->release();

    interruptSource = 0;

}

Источники событий прерывания фильтра

Поддержки Набора I/O совместно использовали прерывания, где драйверы совместно используют единственную линию прерывания. С этой целью это определяет IOFilterInterruptEventSource класс, подкласс IOInterruptEventSource. Apple настоятельно рекомендует, чтобы сторонние писатели драйвера устройства базировали свои источники событий прерывания на IOFilterInterruptEventSource класс вместо IOFilterInterruptEventSource класс. Последний класс не гарантирует, что совместное использование линий прерывания безопасно.

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

Перечисление 7-4 показывает, как установить и использовать IOFilterInterruptEventSource.

Перечисление 7-4  , Создающее IOFilterInterruptEventSource

bool myDriver::start(IOService * provider)

{

    // stuff happens here

    IOWorkLoop * myWorkLoop = (IOWorkLoop *) getWorkLoop();

    if (!myWorkLoop)

        return false;

    // Create and register an interrupt event source. The provider will

    // take care of the low-level interrupt registration stuff.

    //

    interruptSrc =

        IOFilterInterruptEventSource::filterInterruptEventSource(this,

                    (IOInterruptEventAction) &myDriver::interruptOccurred,

                    (IOFilterInterruptAction) &myDriver::checkForInterrupt,

                    provider);

    if (myWorkLoop->addEventSource(interruptSrc) != kIOReturnSuccess) {

        IOLog("%s: Failed to add FIES to work loop.\n", getName());

    }

    // and more stuff here...

}

bool myDriver::checkForInterrupt(IOFilterInterruptEventSource * src)

{

    // check if this interrupt belongs to me

    return true; // go ahead and invoke completion routine

}

void myDriver::interruptOccurred(IOInterruptEventSource * src, int cnt)

{

    // handle the interrupt

}

Если Ваша подпрограмма фильтра ( checkForInterrupt подпрограмма в Перечислении 7-4) возвраты true, Набор I/O автоматически запустит Вашу подпрограмму обработчика прерываний на Вашем цикле работы. Прерывание останется отключенным в аппаратных средствах до Вашей процедуры обработки прерывания (interruptOccurred в Перечислении 7-4), завершается.

Используя обработчиков прерываний без циклов работы

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

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

Больше информации об этом предмете является предстоящим.

Вызовы и вниз вызывают

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

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

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

Настраивая и Используя логические элементы команды

До закрытия логического элемента команды необходимо соответственно подготовить запрос I/O. Запрос I/O включает три вещи: сама команда (который специфичен для семьи), память, вовлеченная в передачу (определенный как IOMemoryDescriptor возражают), и функция для вызова для обработки запроса в контексте логического элемента команды. Посмотрите Управляющие Данные для получения информации о IOMemoryDescriptors и связанных объектах.

Логические элементы команды должны быть закрыты на самый краткий период, в течение которого выполняется наименьшее количество возможного объема работы. Чем дольше логический элемент команды содержит блокировку цикла работы, тем больше вероятность конкуренции. Как со всеми источниками событий, функция логического элемента команды не должна выделять память или любой другой неограниченный ресурс из-за опасности блокировать. Вместо этого клиент должен предварительно выделить требуемые ресурсы, прежде чем управление будет передано контексту цикла работы. Например, это могло выделить пул ресурсов в start функция.

Вы создаете IOCommandGate объект путем вызова commandGate метод фабрики, указывая как параметры объектного «владельца» источника события (обычно this) и указатель на функцию, соответствующую Action прототип. Вы тогда регистрируете логический элемент команды в использовании цикла работы клиента IOWorkLoop addEventSource функция. Перечисление 7-7 дает пример этой процедуры.

  Создание перечисления 7-7 и регистрация логического элемента команды

workLoop = (IOWorkLoop *)getWorkLoop();

commandGate = IOCommandGate::commandGate(this,

                 (IOCommandGate::Action)receiveMsg);

if (!commandGate ||

    (workLoop->addEventSource(commandGate) != kIOReturnSuccess) ) {

    kprintf("can't create or add commandGate\n");

    return false;

}

IOCommandGate класс обеспечивает две альтернативы для инициирования выполнения запроса I/O в логическом элементе команды. Каждый runCommand функция членства и другой runAction функция членства. Эти функции работают так же. Когда клиент хочет вызвать Action функция, вместо того, чтобы вызвать его непосредственно, это вызывает логический элемент команды runCommand или runAction функция, передающая во всех обязательных аргументах. Логический элемент команды тогда захватывает блокировку цикла работы (т.е. это закрывает логический элемент команды), вызывает Action функция, и затем открывает логический элемент.

То, где две функции отличаются, находится в их гибкости. runCommand функция использует тот же механизм цели/действия, используемый другими классами источника события. В этом механизме, создаваемом IOCommandGate объект инкапсулирует (указатель на) Action функционируйте, а также цель (или «владелец») возражают, что реализует эту функцию. В этой модели, только одном Action функция может быть вызвана для запроса I/O.

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

Перечисление 7-8 иллюстрирует один использование runCommand функционируйте для выпуска запроса I/O.

Перечисление 7-8  Выпуская I/O запрашивает через логический элемент команды

void ApplePMU::enqueueCommand ( PMUrequest * request )

{

    commandGate->runCommand(request);

}

void receiveMsg ( OSObject * theDriver, void * newRequest, void *, void *, void * )

{

    ApplePMU * PMUdriver = (ApplePMU *) theDriver;

    PMUrequest * theRequest = (PMUrequest*)newRequest;

    // Inserts the request in the queue:

    theRequest->prev = PMUdriver->queueTail;

    theRequest->next = NULL;

    if ( PMUdriver->queueTail != NULL ) {

        PMUdriver->queueTail->next = theRequest;

    }

    else {

        PMUdriver->queueHead = theRequest;

    }

    PMUdriver->queueTail =  theRequest;

    // If we can, we process the next request in the queue:

    if ( (PMUdriver->PGE_ISR_state == kPMUidle) && !PMUdriver->adb_reading) {

        PMUdriver->CheckRequestQueue();

    }

}

В этом примере, runCommand функция используется для косвенного вызова логического элемента команды Action функция, receiveMsg. Одна важная тактика, которая - этот пример шоу то, как задержать обработку запросы I/O — когда выделение памяти и других ресурсов могло бы быть необходимым — до больше событий, ставится в очередь в логическом элементе команды. receiveMsg если больше запросов не находится на рассмотрении, a вызовов, функция стоит в очереди каждый входящий запрос и CheckRequestQueue функция для выполнения фактической работы I/O.

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

Вы уничтожаете источник события логического элемента команды в водительской функции деактивации (обычно stop). Перед выпуском IOCommandGate объект, необходимо удалить его из цикла работы. Перечисление 7-9 дает пример того, как сделать это.

Перечисление 7-9  , избавляющееся IOCommandGate объект

if (commandGate) {

    myWorkLoop->removeEventSource(commandGate);

    commandGate->release();

    commandGate = 0;

}