Perché gli interrupt devono essere disattivati quando si trova all'interno di un altro codice di interruzione?

There are two types of interaction between the CPU and the rest of the computer's hardware. The first type is when the CPU gives orders to the hardware, the other is when the hardware needs to tell the CPU something. The second, called interrupts, is much harder to implement because it has to be dealt with when convenient for the hardware, not the CPU. Hardware devices typically have a very small amount of RAM, and if you don't read their information when available, it is lost.

Under Linux, hardware interrupts are called IRQ's (InterruptRe quests). There are two types of IRQ's, short and long. A short IRQ is one which is expected to take a very short period of time, during which the rest of the machine will be blocked and no other interrupts will be handled. A long IRQ is one which can take longer, and during which other interrupts may occur (but not interrupts from the same device). If at all possible, it's better to declare an interrupt handler to be long.

When the CPU receives an interrupt, it stops whatever it's doing (unless it's processing a more important interrupt, in which case it will deal with this one only when the more important one is done), saves certain parameters on the stack and calls the interrupt handler. This means that certain things are not allowed in the interrupt handler itself, because the system is in an unknown state.

The solution to this problem is for the interrupt handler to do what needs to be done immediately, usually read something from the hardware or send something to the hardware, and then schedule the handling of the new information at a later time (this is called the "bottom half") and return. The kernel is then guaranteed to call the bottom half as soon as possible -- and when it does, everything allowed in kernel modules will be allowed.

link

Il problema generale è che un gestore di interruzioni di solito manipola le strutture di dati e corrompe quelle strutture di dati se lo stesso codice è stato reimmesso a metà aggiornamento. Tuttavia, esistono molti modi per organizzare i sistemi di interruzione e molti di questi modi consentono interruzioni annidate a diversi livelli di priorità. I controllori di interrupt possono mascherare interrupt che non sono ancora stati riconosciuti dal codice di gestione degli interrupt, quindi è un'istruzione troppo ampia per dire che è "non sicuro avere un interrupt all'interno di un interrupt". Dipenderà dal design del controller di interrupt (hardware) e dai gestori di interrupt (software), nonché dalle caratteristiche del dispositivo di interruzione e dal significato dell'interrupt.

Molti sistemi utilizzano interrupt sensibili al livello. Ciò significa che ogni volta che un particolare interrupt viene abilitato e l'interrupt è attivo, chiamerà il gestore associato a quell'interrupt alla prima opportunità (generalmente ogni volta che termina un'istruzione). Se un interrupt veniva lasciato abilitato mentre era servito, non appena il processore terminava l'elaborazione della prima istruzione di un gestore di interrupt, eseguiva immediatamente un'altra chiamata allo stesso gestore di interrupt, eseguiva un'istruzione, quindi eseguiva un'altra chiamata a quel gestore , ecc. e bombarderebbe lo stack senza mai avere la possibilità di fare alcun lavoro utile nel gestore di interrupt.

Anche se è possibile che un sistema elabori un interrupt come una risposta una tantum e ignori la linea di interruzione fino al prossimo verificarsi della condizione, può essere difficile rendere tali progetti funzionanti in modo affidabile se gli interrupt possono diventare attivi mentre vengono sottoposti a manutenzione (ad es. una porta seriale riceve un carattere mentre la CPU sta elaborando un carattere precedente). Un vantaggio degli interrupt sensibili al livello è che se uno stimolo di interruzione arriva tra il momento in cui il gestore ha elaborato il precedente da quella fonte e il tempo che ritorna, l'atto di ritorno riabiliterà l'interruzione e causerà il gestore essere rieseguito per gestire il nuovo stimolo. Il sistema potrebbe bloccarsi se un interrupt non è mai in grado di soddisfare il dispositivo che richiede un interrupt, ma tali problemi sono spesso più facili da eseguire nel debug rispetto ai problemi che possono verificarsi quando si utilizzano interrupt triggerati dal fronte se la CPU non può rispondere a uno stimolo con precisione quando si verifica e di conseguenza finisce per non rispondervi mai.