На какой вектор прерывания вешать своё устройство?

[KA3AKOB]

Собрана этажерка из плат фирмы Fastwel: CPC30402 + DIC310 с загруженной в FPGA прошивкой. Нужно написать QNX resource manager под эту прошивку. Возник ряд вопросов:
1)Векторов прерываний, вообще говоря, мало. В методическом руководстве описывается программа обработчик прерывания под систему MS-DOS (FDOS). В ней при инициализации новой программы обработки прерываний старый указатель из вектора, на какой бы обработчик он не указывал, сохраняется, новый вектор содержит указатель на новый обработчик, а в новом обработчике после выполнения своих дел, вызывается старый обработчик по сохранённому указателю. Таким образом, на один вектор прерывания вешается несколько устройств. Но это в DOS. Как это делается в QNX?
2) Как извлечь старый указатель из вектора? С помощью какой функции?
3) В каком потоке менеджера ресурсов работает обработчик прерывания, если в менеджере (драйвере) таких потоков несколько? В том потоке, который издал вызов InterruptAttach()?
4) IRQ5, рекомендуемый в методическом примере DOS, в реальной системе QNX, судя по описанию, используется сетевым адаптером. Сеть отрубать не следует. Как совместить своё устройство со стандартным сетевым адаптером?
5) Прежний обработчик прерывания наверняка находится за пределами адресного пространства моего драйвера (менеджера ресурсов), как избежать Access Violation? Или вызов функции InterruptAttach избавляет разработчика от забот и сам сохраняет прежний указатель из вектора и сам вызывает прежний обработчик прерывания? В книжке Кртена пример не содержит ни сохранения прежнего указателя из вектора IRQ5, ни вызова прежнего из нового обработчика.
6) В примере для DOS сброс прерывания выполняется выдачей команды outportb(0x20, 0x20).  Нужно ли выполнять эту команду в QNX?
7) Глядя в осциллоскоп, на взвод сигнала прерывания и его сброс с удивлением обнаружил, что запросы прерываний чаще, чем через 300 миллисекунд обрабатываются не все. То есть сброс прерывания из моего обработчика происходит через очень большой интервал времени. Это время значительно превышает период передиспетчеризации в системе QNX, по моим сведениям: стандартно 4 миллисекунды. Такое наводит на подозрения, что при обработке прерывания тоже произошла передиспетчеризация потоков в системе. Но в Кртене говорится, что если использовал InterruptAttach(), а не InterruptAttachEvent(), то передиспетчеризации не происходит, правда, тогда в обработчике прерывания нельзя делать вызовы системных функций, кроме крайне ограниченного числа оных. Я и не делаю, вызываю только in8(), out8(). Буквально несколько строк. Почему же так долго отзывается?
8 ) Опять же, в DOSовском примере при завершении программы восстанавливается старый указатель на обработчик прерывания. Но завершить драйвер QNX, можно только через kill -9 nnn, а этот сигнал не перехватывается пользователем. Система что-то совершает волшебным образом и процесс исчезает. Но для восстановления старого указателя в векторе и ещё кое-каких завершающих действий с прошивкой, мне надо, чтобы по перехвату сигнала отработал мой завершающий модуль.
9 ) Не может ли железо сетевого адаптера как-то тормозить мой драйвер?

Вопросов много, но ответы нужны.
С уважением,
Казаков С.А.

[Владимир Махилёв]

По поводу общего понимания работы с прерываниями в QNX рекомендую ознакомиться со статьёй из русскоязычной документации:
Микроядро QNX Neutrino. Обработка прерываний
И также Writing an Interrupt Handler и справкой на функции InterruptAttach()/InterruptAttachEvent()

Отвечая на вопросы (насколько я их понял):
- На одно аппаратное прерывание можно навесить несколько обработчиков, при возникновении прерывания они будут вызываться последовательно. Ситуация когда происходит разделение одного прерывания между различными устройствами (сеть, USB и т.п.) совершенно штатная и в таком случае каждый драйвер должен отвечать только за своё устройство.
- Обработчик прерывания, добавленный с помощью InterruptAttach, работает в контексте ядра (доступный ему объём памяти и количество доступных действий ограничено). Обработчик InterruptAttachEvent() работает в контексте пользовательского процесса и на его приоритете.
- По поводу работы с оборудованием (чтением-записью в порты) лучше обратиться к документации или имеющимся исходным кодам/примерам. Если вы разрабатываете драйвер с обработчиком прерывания, то как минимум необходимо сбрасывать источник прерывания. Сохранять указатели при перезапуске программы не нужно.
- Пропусков или задержек обработки прерываний при таких больших интервалах времени быть однозначно не должно. Считаю, что необходимо искать причину таких пропусков/задержек в первую очередь в коде драйвера.
- По  выполнению пользовательского кода при завершении процесса - необходимо добиться корректной реакции драйвера на штатный сигнал SIGTERM. После этого вы сможете навесить обработчик этого сигнала, например, с помощью функции signal()

[Василий Дмитриев]

Глядя в осциллоскоп, на взвод сигнала прерывания и его сброс с удивлением обнаружил, что запросы прерываний чаще, чем через 300 миллисекунд обрабатываются не все.

Это явно из области аномалий. Обрабатывал прерывания с частотой 3 миллисекунды на cpc304 как под qnx4, так и под qnx6. По моим прикидкам время реакции (передача Вашему обработчику)  на этой плате д.б. не более 1.5 мкс. Насколько я помню сей продукт, то там очень грустный биос, с отнюдь не прозрачной настройкой прерываний.