He rastreado la web, pero no he encontrado una respuesta convincente a un par de preguntas relacionadas que tengo, con respecto a la función "request_threaded_irq".

Pregunta 1: En primer lugar, estaba leyendo este artículo, con respecto a las IRQ con hilos:

http://lwn.net/Articles/302043/

Y hay una línea que no me queda clara:

"Convertir una interrupción en subproceso solo tiene sentido cuando el código del manejador lo aprovecha integrando la funcionalidad tasklet / softirq y simplificando el bloqueo".

Entiendo que si hubiéramos seguido adelante con un enfoque "tradicional", mitad superior / mitad inferior, habríamos necesitado giros o deshabilitar IRQ local para entrometerse con datos compartidos. Pero, lo que no entiendo es cómo las interrupciones de subprocesos simplificarían la necesidad de bloquear integrando la funcionalidad tasklet / softirq.

Pregunta 2: En segundo lugar, ¿qué ventaja (si la hay), tiene un enfoque request_threaded_handler sobre una aproximación de work_queue bottom half half? En ambos casos parece, como si el "trabajo" se aplace a un hilo dedicado. Entonces cuál es la diferencia ?

Pregunta 3: Por último, en el siguiente prototipo:

int request_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t thread_fn, unsigned long irqflags, const char *devname, void *dev_id)

¿Es posible que la parte "manejadora" de la IRQ sea activada de manera continua por la IRQ relevante (por ejemplo, un UART receving caracteres a una tasa alta), incluso cuando la parte "thread_fn" (escritura de bytes en un búfer circular) forma parte de ¿el manejador de interrupciones está ocupado procesando IRQ de activaciones anteriores? Entonces, ¿el controlador no estaría tratando de "activar" un "thread_fn" ya en ejecución? ¿Cómo se comportaría el irq thread_fn en ese caso?

Realmente apreciaría si alguien me puede ayudar a entender esto.

Gracias vj