Похоже, что все наши проблемы решены! Будем использовать режим чувствительности по фронту и жить счастливо. Но, к сожалению, у режима чувствительности по фронту тоже есть свои проблемы.
Предположим, что ваш ISR не очистил источник прерывания. Когда ядро выдаст контроллеру сигнал EOI, аппаратные средства будут по-прежнему удерживать сигнал прерывания в активном состоянии. Однако, поскольку контроллер работает в режиме чувствительности по фронту, все последующие прерывания от этого устройства он не увидит.
Что же это за добрый парень, который так пишет ISR, чтобы тот забыл очистить источник прерывания? К сожалению, готовых рецептов здесь нет. Представьте себе ситуацию, когда два устройства (например адаптер SCSI и адаптер Ethernet), разделяющих одну и ту же линию прерывания на позволяющей это шине. (Сейчас вы скажете: «Да ну, какой придурок будет так делать?!» Ну, это иногда случается, особенно когда не хватает свободных прерываний...)
В этом случае одному и тому же вектору прерывания соответствовали бы два ISR (это, кстати, допустимо), и ядро при получении прерывания по этой линии вызывало бы их каждый раз поочередно.
Разделяемые прерывания без перекрытия.
В этом случае, поскольку только одно из аппаратных устройств (плата SCSI) было активно, когда отработал связанный с ним обработчик корректно очистил источник прерывания (этап 2.) Отметьте, что ядро вызывает ISR для платы Ethernet (этап 3) независимо ни от чего — оно просто не знает, какое конкретное устройство требовало обслуживания, поэтому всегда отрабатывает всю цепочку.
А теперь представьте себе другой случай:
Разделяемые прерывания с перекрытием.
Это как раз та самая проблемная ситуация.
Устройство Ethernet запрашивает прерывание первым. Это приводит к тому, что выставляется сигнал прерывания (передний фронт импульса распознается контроллером прерываний), и ядро вызывает первый в очереди обработчик прерывания (драйвер SCSI; этап 1). Обработчик драйвера SCSI смотрит на свои аппаратные средства и говорит: «Не, это не мое. Ладно, забудь» (этап 2). Затем ядро вызывает следующий обработчик прерывания в очереди, соответствующий плате Ethernet (этап 3). Обработчик драйвера Ethernet смотрит на свои аппаратные средства и восклицает: «О! Мои аппаратные средства запросили прерывание! Надо очистить источник». И тут, как назло, как раз в процессе очистки устройство SCSI генерирует прерывание (этап 4).
Когда ISR платы Ethernet завершит очистку источника прерываний (этап 5), сигнал прерывания по-прежнему останется выставлен вследствие возникшего прерывания от устройства SCSI. Однако, контроллер прерываний, запрограммированный на режим чувствительности по фронту, реагирует на переход группового сигнала прерывания из неактивного состояния в активное. А этого не будет, потому что ядро уже вызвало оба обработчика прерываний и теперь ждет другое прерывание от контроллера.
В этом случае подходящим решением был бы режима чувствительности по уровню, потому что когда ISR Ethernet завершится, и ядро выдаст контроллеру сигнал EOI, контроллер сможет распознать, что сигнал прерывания все еще активен, и прервет ядро заново. Тогда ядро снова прошло бы по всей цепочке ISR, и на этот раз обработкой занялся бы ISR драйвера SCSI.
Выбор режима чувствительности зависит от типа аппаратных средств и стартового кода. Некоторые аппаратные средства поддерживают только либо один, либо другой режим. Аппаратные средства, которые поддерживают оба режима, могут быть запрограммированы на тот или иной режим стартовым кодом. За окончательным ответом обращайтесь к документации по BSP (Board Support Package — пакет поддержки платы), поставляемого с вашей системой.
Написание обработчиков прерываний
Давайте посмотрим, как настроить обработчики прерываний — вызовы, характеристики и кое-какие стратегии реализации.
Подключение обработчиков прерываний
Для подключения к источнику прерывания воспользуйтесь функцией InterruptAttach() или InterruptAttachEvent().
#include <sys/neutrino.h>
int InterruptAttachEvent(int intr,
const struct sigevent *event, unsigned flags);
int InterruptAttach(int intr,
const struct sigevent* (*handler)(void *area, int id),
const void *area, int size, unsigned flags);
Параметр intr определяет, к какому прерыванию вы хотите подключить обработчик.
Передаваемые значения определяются стартовым кодом, который перед запуском QNX/Neutrino, среди прочего, инициализирует контроллер обработки прерываний. (В документации по QNX/ Neutrino приводится подробная информация о стартовом коде; см. Справочник по утилитам, главы startup-*, например, startup-p5064.)
Уже здесь функции InterruptAttach() и InterruptAttachEvent() различаются. Рассмотрим сначала функцию InterruptAttachEvent(), как более простую. Затем вернемся к рассмотрению функции InterruptAttach().
Функция InterruptAttachEvent() принимает два дополнительных аргумента: event, который является указателем на структуру struct sigevent, описывающую генерируемое событие, а также flags. Функция InterruptAttachEvent() сообщает ядру, что при обнаружении прерывания должно быть сгенерировано событие event, после чего данный уровень прерываний должен быть демаскирован. Отметьте, что за то, как интерпретировать событие и какой поток перевести в состояние READY, отвечает ядро, при обнаружении прерывания.
При использовании функции InterruptAttach() мы определяем другой набор параметров. Параметр handler — это адрес функции, которую надо вызвать. Как видно из прототипа, функция handler() возвращает структуру struct sigevent (указывающую на тип события, которое следует сгенерировать) и принимает два параметра. Первый передаваемый параметр — area, тот самый, который передается функции InterruptAttach(). Второй параметр, id, — идентификатор прерывания, его также возвращает InterruptAttach(). Он применяется для идентификации прерывания, а также для маскирования, демаскирования, блокировки и деблокировки прерывания. Четвертый параметр InterruptAttach(), size, указывает размер (в байтах) области данных, которая передается в параметре area. И, наконец, пятый параметр — flags — тот же самый параметр flags, что и у InterruptAttachEvent(); мы скоро к нему вернемся.
Допустим, что вы уже вызвали функцию InterruptAttachEvent() или InterruptAttach().
Поскольку подключение к прерываниям — не та вещь, которую вы хотели бы позволять кому попало, QNX/Neutrino позволяет делать это только потокам, у которых есть право «привилегированного ввода/вывода» («I/O privity») (см. функцию ThreadCtl() в справочном руководстве по Си-библиотеке QNX/Neutrino). Получить это право могут только потоки, которые выполняются под идентификатором пользователя root или которые установили свой идентификатор пользователя в root при помощи setuid(). Следовательно, реально эти права есть только у root. (Что, кстати, вполне логично — зачем несуперпользовательскому процессу привилегированный ввод/вывод? — прим. ред.)