обработка прерывания программного обеспечения ядра

Это пахнет как домашняя работа, но я попробую ее.

То, на что это походит мне, является этим, говорит, что программные прерывания (которые не являются тем же как исключениями, возможно!) в недетерминированные времена. В основном ОС хочет быть эффективной, и может обработать их как часть другого прерывания (аппаратные средства, которыми это кажется), или когда Вы входите, пространство ядра (скажите, выполните запрос ядра.)

Что касается обработки прерывания фронтенда, это более или менее говорит, что ядро получает выстрел прежде и после каждого прерывания, которое обрабатывается. Например, некоторые не могут быть переданными пользовательскому коду, неважно, как трудно Вы пробуете. Ядро просто обрабатывает его и никогда не позволяет пользователю кодировать касание он. Другие могли бы быть столь же простыми, как установка другого стека для обработки прерывания, затем позволяя пользователю кодировать пробует его. Если ни один из кода уровня пользователя не обработает его, то это в конечном счете примет некоторые меры по умолчанию.

Мне это, кажется, говорит, что программные прерывания обрабатываются любой A) в той же части ядра кодируют как аппаратные прерывания, или B) ядро ничего не делает в тот момент времени, когда программное прерывание происходит, но будет помнить, что прерывание произошло, и когда функция, связанная с программным прерыванием, вызвана, обработает прерывание затем.

Windows имеет что-то позвонившее "Отложенный вызов процедуры" (DPC), где объем обработки прерывания задерживается до удобного времени. Это делает это, потому что x86 единственный ЦП имеет одну линию IRQ, которая мультиплексируется внешней PIC или APIC. Когда IRQ инициирован, ЦП автоматически отключает IRQs, пока процедура обработки прерывания не повторно включает им. Но с тех пор существует только одна линия IRQ, которая означает, когда IRQs отключены, который означает, что все IRQs отключены. архитектура x86 имеет много устройств с помощью IRQs так, чтобы были отключены средства, действительно, что система (или по крайней мере что конкретный ЦП) является видом державших в заложниках в течение времени IRQs. Таким образом механизм DPC существует, чтобы гарантировать, что IRQs выключены в течение наименьшего количества необходимого времени. Идеальная вещь состоит в том, чтобы ISR сделал абсолютную минимальную обработку, необходимую прежде, чем повторно включить IRQs, и смещает остальную часть работы к DPC.

Я мог быть неправым, но я думаю, что программные прерывания отключают IRQs автоматически также. Таким образом даже при том, что программное прерывание не имеет ввода-вывода к сервису, это все еще вызывает систему, ЦП / единственный ЦП для не сможения обслуживают другие прерывания, пока обработчик прерываний не повторно включает им.

Системные вызовы с помощью ассемблера, инструкция INT является программными прерываниями (если Windows не использует другой метод теперь как Linux с, он - прием linux-gate.so), а также исключений ЦП включая отсутствия страницы, делятся на нуль,

Таким образом, все прерывания обрабатываются asychronously в Windows и любой операционной системе действительно, я думаю по вышеупомянутым причинам. Я не эксперт по ядру, или что-либо поэтому просто берет вышеупомянутое в качестве некоторого понимания.