OSDev

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

Естественно, стоит. Без отложенной обработки прерываний не обходится ни одна нормальная ОС.

А точнее, когда происходит прерывание, управление получает драйвер устройства (точней, входящий в его состав первичный обработчик), а уже он, если есть нужда, откладывает обработку прерывания. Ведь сразу разрешать прерывания от устройства может быть недопустимо; кроме того, не каждое прерывание непременно требует отложенной обработки.

Это не совсем отложенная обработка, но накладные расходы будут и возможно сопоставимые.
Просто обработка со включенными других прерываниями и в определённом контексте.
EOI не снимает прерывание с устройства, оно снимает прерывание с контроллера прерывания.

Ясно что не каждое требует, но каждое ли позволяет?

Просто идея размаскировать прерывания. Тем самым я смогу предотвратить ситуацию когда баг в обработчике прерывания вешает всю систему.

Естественно, прерывание на отложенную обработку ставит первичный обработчик. Соответственно все зависит от того, можно ли в твоей системе повесить несистемный первичный обработчик на любое прерывание или нет.

Просто размаскировать прерывания конечно можно, но это криво. Отложенные обработчики не должны прерывать друг друга. А вероятность возникновения ошибки (и подвешивания системы) в первичном обработчике всегда остается, если он плохо написан.

Пишу в псевдокоде.




IRQ1 и IRQ2 и тд. можно подменять. 3-1 Кольцо защиты(3-1 уровень привилегий).
_IRQ1 и _IRQ2 и тд. подменять нельзя. 0 Кольцо защиты(0 уровень привилегий).

IRQ1 к примеру завязан на PCI он должен проверить его ли это прерывания. В вашей терминологии первичный обработчик он и решает вопрос делать прерывание отложенным.

Нет. Ты должен проверять, выполняется ли уже отложенная обработка или нет. В приведенном коде много упущений: риск переполнения стека; риск прерывания отложенного обработчика тем же самым обработчиком; риск разрушения ds:[StateInteruptRet] в IrqProc со стороны _Irq1. В очереди можно сохранять непосредственно адреса отложенных обработчиков. Отложенные обработчики предназначены для режима ядра - они не могут выполняться или обращаться к прикладному пространству, т.к. обычно вызываются в контексте произвольного процесса. Как я уже сказал, отложенные обработчики не должны прерывать друг друга - как минимум сами себя, как максимум себя и любые другие отложенные обработчики. Нужно иметь средство защиты от переполнения очереди, например, наложение отложенных обработчиков одного типа в случае переполнения очереди. Отложенная обработка прерываний может быть не самой приоритетной после работы с запрещенными прерываниями, т.е. прежде чем выполнять отложенную обработку прерываний, нужно еще посмотреть на приоритет кода, который работал до возникновения прерывания. Первичные обработчики можно подменять также, как и отложенные обработчики. Просто есть системные первичные обработчики, которые выполняют всю "скрытую" работу, и не системные, которые вызываются из системных. На одно и то же прерывание может быть повешено несколько не системных первичных обработчиков. Еще и поэтому отложенные обработчики лучше идентифицировать по адресу, а не по номеру прерывания. Ну или ввести уникальную нумерацию.

А почему?

Поверку опустил, ровно как и приоритеты.

Как ты себе это представляешь? Код ядерный другие приложения не могут его менять.

Это понятно. Просто у меня они не в пространстве ядра, а в пространстве драйверов (у него уровень защиты ниже численно больше).

Это будет просто код упростил.