Przeszukałem sieć, ale nie znalazłem przekonującej odpowiedzi na kilka powiązanych pytań dotyczących funkcji „request_threaded_irq”.

Pytanie 1: Po pierwsze, czytałem ten artykuł dotyczący wątków IRQ:

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

i jest ta jedna linia, która nie jest dla mnie jasna:

„Konwersja przerwania na wątek ma sens tylko wtedy, gdy kod obsługi korzysta z tego, integrując funkcjonalność tasklet / softirq i upraszczając blokowanie”.

Rozumiem, że gdybyśmy poszli naprzód z „tradycyjną”, górną połową / dolną połową podejścia, potrzebowalibyśmy albo spin-locków, albo wyłączenia lokalnego IRQ, aby wtrącać się do współdzielonych danych. Ale nie rozumiem, w jaki sposób wątkowe przerwania upraszczają blokowanie poprzez integrację funkcji tasklet / softirq.

Pytanie 2: Po drugie, jaką przewagę (jeśli w ogóle) ma podejście request_threaded_handler w stosunku do metody dolnej połowy opartej na kolejce pracy? W obu przypadkach wydaje się, że „praca” jest odłożona na dedykowany wątek. Jaka jest różnica?

Pytanie 3: Wreszcie w następującym prototypie:

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)

Czy jest możliwe, że część IRQ „handler” jest ciągle wyzwalana przez odpowiednie IRQ (powiedzmy, że UART odbiera znaki z dużą szybkością), nawet gdy „thread_fn” (zapisując bajty rx do bufora kołowego) część program obsługi przerwań jest zajęty przetwarzaniem przerwań z poprzednich pobudzeń? Czy program obsługi nie próbowałby „obudzić” już działającego „thread_fn”? Jak działa działający wątek irq w tym przypadku?

Naprawdę doceniłbym, gdyby ktoś mógł mi pomóc to zrozumieć.

Dzięki, vj