printk all'interno di un gestore di interrupt, è davvero così male?

Question

tutti sanno che il gestore di interrupt dovrebbe essere il più corto possibile. e l'aggiunta di funzioni come printk per il debug all'interno di un gestore di interruzioni è qualcosa che non dovrebbe essere fatto. In realtà, l'ho provato prima, quando stavo eseguendo il debug del kernel linux per un dispositivo di char char di interrupt che ho scritto, e distruggeva i tempi del driver.

La domanda che ho, è perché questo sta accadendo? printk la funzione è memorizzata nel buffer! significa, per quanto comprendo, che i dati siano inseriti in una coda e che vengano gestiti in seguito, molto probabilmente dopo che il gestore di interruzioni è finito.

Quindi perché non funziona?

Answer 1

La funzione printk non si limita ad inserire in una coda/buffer - presupponendo che il livello di registrazione sia sufficientemente elevato, l'uscita da printk verrà emessa immediatamente nella console, come parte della chiamata a printk. Questo è particolarmente lento se la console è, per esempio, su una porta seriale. In ogni caso, lo printk introduce un overhead piuttosto sostanziale e può influire sui tempi.

Se si dispone di un punto critico in cui si desidera ottenere un output di debug, è possibile utilizzare la funzione trace_printk nei kernel moderni. Questo in realtà non fa altro che inserire input nel trace ringbuffer, e puoi leggerlo in seguito. Dai uno sguardo allo this article per i dettagli completi.

Answer 2

Sì, è molto male poiché printf molto probabilmente non è rientranti. Ciò che può accadere è che il programma principale chiama printf, un interrupt arriva mentre printf è in esecuzione, quindi il gestore IRQ chiama nuovamente printf: possono accadere cose molto brutte (ad esempio deadlock, buffer interni corrotti, ecc.)