request_any_context_irq(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– request_any_context_irq(9) πŸ’–

okay bestie, so this is a page straight outta the Kernel API Manual β€” the request_any_context_irq(9) entry, and honestly? it's kind of a whole vibe. it's the "idk what kinda IRQ you are but I gotchu" of the kernel. let's get into it 🫢


✨ NAME ✨

request_any_context_irq β€” allocate an interrupt line 🌸

like, you're claiming an interrupt line. that's the whole thing. it's giving reservation-at-a-restaurant energy. πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

int request_any_context_irq (unsigned int irq , irq_handler_t handler ,
unsigned long flags , const char *name , void *dev_id );

five params, no notes, she's iconic. πŸ’…


πŸ‘‘ ARGUMENTS πŸ‘‘

  • irq β€” the interrupt line you're trying to allocate. literally the number of the IRQ you want. this is the main character here. ⭐
  • handler β€” the function that gets called when the IRQ actually happens. and lowkey important: for threaded interrupts, this is the threaded handler. so like, know which one you're dealing with. 🧚
  • flags β€” the interrupt type flags. yeah, those flags. the ones that say what kind of interrupt this is. πŸŽ€
  • name β€” an ascii name for the claiming device. it's literally just a label so everyone knows whose interrupt this is. name your device, bestie, it deserves one. πŸ’œ
  • dev_id β€” a cookie passed back to the handler function. yes, an actual cookie (metaphorically). it's the little thing that gets handed back to your handler so it knows what's up. πŸ“

πŸ”₯ DESCRIPTION πŸ”₯

so what does this call even do? okay so:

it allocates the interrupt resources, and then it enables both the interrupt line and IRQ handling. all in one go. ate, honestly.

and here's the slay part β€” it selects either a hardirq or threaded handling method, depending on the context. so you don't have to pick, she picks for you. it's giving "don't worry your pretty little head about it" energy. 😭✨

ngl the whole point of this one is that it's context-aware, so if you're choosing between this and request_threaded_irq(9), this is the "let the kernel decide" option. periodt.

🌈 RETURN 🌈

  • on failure, it returns a negative value. sad. πŸ’€
  • on success, it returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED. πŸŽ‰

so like β€” check your return value, bestie. negative means go cry about it, and the other two tell you which handling vibe you got. iykyk. πŸ’…


🌸 SEE ALSO 🌸

first up, the kernel file: ./kernel/irq/manage.c β€” go read her if you want the behind-the-scenes. πŸ“–

and then the whole extended friend group, fr fr:

synchronize_hardirq(9), synchronize_irq(9), irq_can_set_affinity(9), irq_can_set_affinity_usr(9), irq_set_thread_affinity(9), irq_affinity_schedule_notify_work(9), irq_update_affinity_desc(9), irq_set_affinity(9), irq_force_affinity(9), irq_set_affinity_notifier(9), irq_set_vcpu_affinity(9), disable_irq_nosync(9), disable_irq(9), disable_hardirq(9), disable_nmi_nosync(9), enable_irq(9), enable_nmi(9), irq_set_irq_wake(9), irq_wake_thread(9), free_irq(9), request_threaded_irq(9), request_nmi(9), irq_percpu_is_enabled(9), free_percpu_irq(9), request_percpu_irq_affinity(9), request_percpu_nmi(9), prepare_percpu_nmi(9), teardown_percpu_nmi(9), irq_get_irqchip_state(9), irq_set_irqchip_state(9), irq_has_action(9), irq_check_status_bit(9)

like, that's the whole gc right there. go say hi. πŸ«ΆπŸ’–


and that's the page!! mwah πŸ’‹ this lil masterpiece lives in ./kernel/irq and it's dated October 2026 β€” so yeah, she's from the future, obviously. see u next time bestie, stay slaying those interrupts πŸ‘‘πŸŽ€βœ¨

πŸ“¦ where this page comes from