um_request_irq_tt(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ um_request_irq_tt(9) ✨

okay so bestie, welcome to the Kernel API Manual page for um_request_irq_tt β€” that's the one and only request an IRQ with timetravel handler πŸ•°οΈβœ¨ this is the UML (user-mode Linux) side of things, and yes it's giving main character energy.


🌸 SYNOPSIS 🌸

like, here's the whole vibe in one line:

int um_request_irq_tt (int irq , int fd , enum um_irq_type type ,
irq_handler_t handler , unsigned long irqflags , const char *devname ,
void *dev_id , void (*timetravel_handler)(int, int, void *, struct
time_travel_event *) );

eight arguments, no cap. let's get into them πŸ’…


πŸŽ€ ARGUMENTS πŸŽ€

  • irq β€” the IRQ number, or UM_IRQ_ALLOC if you're feeling "allocate me one, king" 🫢
  • fd β€” The file descriptor to request an IRQ for
  • type β€” read or write β€” pick your lane, bestie
  • handler β€” the (generic style) IRQ handler
  • irqflags β€” Linux IRQ flags
  • devname β€” name for this to show
  • dev_id β€” data pointer to pass to the IRQ handler
  • timetravel_handler β€” the timetravel interrupt handler, invoked with the IRQ number, fd, dev_id and time-travel event pointer. yes literally all four, she's thorough πŸ’–

⭐ RETURN ⭐

The interrupt number assigned or a negative error. so like, a number = slay, negative = 😭.


πŸ”₯ DESCRIPTION πŸ”₯

okay this is the important part so pay attention bestie πŸ‘‘

Note that the timetravel handler is invoked only if the time_travel_mode is TT_MODE_EXTERNAL, and then it is invoked even while the system is suspended! even. while. suspended. she does not care about your nap schedule πŸ’€

This function must call time_travel_add_irq_event for the event passed with an appropriate delay, before sending an ACK on the socket it was invoked for. like, delay first, ACK second. in that order. no skipping steps πŸ™ˆ

If this was called while the system is suspended, then adding the event will cause the system to resume. so yeah, your event is basically the alarm clock ⏰✨

Since this function will almost certainly have to handle the FD's condition, a read will consume the message, and after that it is up to the code using it to pass such a message to the handler in whichever way it can. (the message is gone once you read it β€” you gotta hand it off yourself, that's your problem now 🫢)

If time_travel_mode is not TT_MODE_EXTERNAL the timetravel_handler will not be invoked at all and the handler must handle the FD becoming readable (or writable) instead. Use um_irq_timetravel_handler_used to distinguish these cases. iykyk β€” that's the whole vibe check right there.

See virtio_uml.c for an example. (go look, it's iconic πŸ‘€)

⚠️ heads up bestie: the timetravel handler firing while suspended is real, not a rumour, and if you skip the time_travel_add_irq_event call before the ACK you're gonna have a bad time πŸ’…

🌈 SEE ALSO 🌈

Kernel file ./arch/um/include/shared/irq_kern.h β€” go read it, it's right there πŸ’œ


and that's the page fr fr πŸ“ this little gem came out of ./arch/um/include/shared, dated October 2026 β€” mwah, iconic, no notes πŸ’…βœ¨πŸ§š

πŸ“¦ where this page comes from