printk dentro de un manejador de interrupciones, ¿es realmente tan malo?

Question

todos saben que el controlador de interrupciones debe ser lo más corto posible. y agregar funciones como printk para la depuración dentro de un manejador de interrupciones es algo que no se debe hacer. En realidad, lo intenté antes cuando estaba depurando el kernel de Linux para un dispositivo de char de interrupción que escribí, y arruinó el tiempo del controlador.

La pregunta que tengo, ¿por qué está sucediendo esto? printk ¡la función está en el búfer! significa, por lo que entiendo, que los datos se insertan en una cola, y que se están manejando más tarde, muy probablemente después de que el controlador de interrupciones haya finalizado.

¿Por qué no funciona?

Answer 1

La función printk no solo se inserta en una cola/búfer: suponiendo que el nivel de registro sea lo suficientemente alto, la salida de printk se emitirá a la consola inmediatamente, como parte de la llamada al printk. Esto es especialmente lento si la consola está, por ejemplo, en un puerto serie. Pero en cualquier caso, printk sí introduce una sobrecarga considerable y puede afectar el tiempo.

Si tiene un lugar crítico de tiempo en el que desea obtener algún resultado de depuración, puede verlo utilizando la función trace_printk en núcleos modernos. De hecho, esto solo pone entrada en el anular de rastreo y puede leerlo más tarde. Eche un vistazo a this article para más detalles.

Answer 2

Sí, es muy malo ya que printf probablemente no sea reentrante. Lo que puede ocurrir es que el programa principal invoque printf, se produzca una interrupción mientras se ejecuta printf, y luego el manejador de IRQ vuelve a llamar al printf: pueden ocurrir cosas muy malas (por ejemplo, interbloqueo, búferes internos corruptos, etc.)