OSDev

Можно опрашивать регистры контроллера прерываний и по ним выяснить, какие прерывания находятся с его точки зрения в обработке (для которых не были выданы команды "конец прерывания"). Поскольку прерывания обрабатываются в соответствии с приоритетами, самое приоритетное из обрабатываемых и будет тем, что произошло последним. Так что реализовать программное определение номера линии IRQ возможно. Другое дело, что особого смысла в этом лично я не вижу.

У меня микроядро. Серверы могут попросить ядро при приходе определённого прерывания послать им сообщение. Все пользовательские обработчики у меня в списке. Там указан номер, нить сервера и какое сообщение посылать. Вот для этого мне и надо определять номер IRQ.
Узнать номер прерывания как я понимаю можно из регистров ISR Local APIC.
UPD: Вот что получилось:

Может быть кому-нибудь пригодится. Если можно сделать что-то оптимальнее, то можете мне подсказать.

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

Опять же проверь, это не работает только в Bochs, или вообще везде. И в конце обработчика прерывания так же должна быть отправка сигнала EOI. У меня работает в качестве основного генератора, и в Bochs работает.

По поводу универсальной обработки стандартного таймера. Можно не маскировать IRQ0 в IO-APIC, а должны быть замаскированы сами PIC1 и PIC2. В итоге, прерывания будут поступать всегда: либо через IRQ0, либо через IRQ2.


Я даже не выяснял. Я следую правилу: чем меньше вычислений, тем меньше ошибок. А ты словно ищешь чем бы процессор загрузить, чтоб не дремал :)

EOI ;)

Ну ладно. С помощью препроцессора размножу обработчики, которые запихнут в стек RAX, затем присвоят ему номер IRQ и прыгнут на главную часть обработчика. Тот вариант, что сейчас своеобразная оптимизация по размеру. Если я сделаю отдельные обработчики - будет по скорости.

Учитывая объёмы памяти, оптимизация по скорости важнее. Тем более что чтение регистров контроллеров иногда выполняется _чрезвычайно_ медленно (сотни тактов процессора).