OSDev

Во всех примерах, которые я видел, PIC настраивается на явную команду EOI, однако, для аппаратных прерываний в IDT используются шлюзы прерываний (а не ловушек), поэтому процессор сам запрещает прерывания при передаче управления обработчику прерывания. Почему бы тогда не использовать неявный EOI? И не писать outportb (0x20. 0x20) в конце каждого обработчика прерываний от ведущего PIC?

Контроллер прерываний может делать независимую задержку по каждому типу прерывания, а проц если и делает задержку, то не различает тип прерывания. Т.е. при автоматическом EOI для процессора могут быть потеряны все прерывания нек. устройства, а при явном EOI можно сохранить хотя бы по одному прерыванию от каждого устройства. Я понимаю это так. Если не прав, поправьте.

В своё время я тоже сначала думал использовать автоматический EOI, но потом осознал, что он создаст мне лишние проблемы. А вот в чём дело -- не помню. Возможно, в том, что я стремлюсь как можно быстрей разрешить прерывания процессора, а при автоматическом EOI это нельзя делать до тех пор, пока не запрещены прерывания от устройства, вызвавшего прерывания -- ведь тогда прерывание возникнет снова. С "ручным" же EOI прерывания от этого устройства (и всех других с таким же и более низким приоритетом) будут запрещены контроллером прерываний, а значит, можно разрешать прерывания очень быстро -- прервать работу смогут лишь более приоритетные прерывания.

http://ru.osdev.wikia.com/wiki/Программируемый_контроллер_прерываний - здесь лучше всего объяснено про режимы работы контроллера прерываний.

Как я понимаю, явный режим EOI нужен для того, чтобы низко приоритетное прерывание не прервало обработчик более приоритетного прерывания. Однако, процессор сбрасывает флаг IF при передаче управления обработчику прерывания через шлюз прерывания. Поэтому прерывание, например, от таймера никогда не прервёт обработчик прерывания от диска. Вот я и интересуюсь - может использовать неявный EOI?

Ну так это Вам и решать -- зависит-то от требований к системе и логики её реализации. Вообще говоря, длительная работа при запрещённых прерываниях нежелательна, и именно поэтому их надо как можно быстрее разрешать. Однако сразу разрешить нельзя, а собственных средств для частичного разрешения прерываний у процессора нет.

Кстати говоря, если разрабатывать под современное железо, то возиться с PICом особого резона нет: уже давным-давно используется APIC, а это совершенно другая железяка.