ENUM UM_TIMETRAVEL_OPS(9)

🌈 enum um_timetravel_ops — Operation codes 🎀

okay so bestie, welcome to the Kernel API Manual page for enum um_timetravel_ops — yes it's a whole enum of time-travel operation codes and yes it's iconic 💅 like, the kernel literally has a time machine and these are the buttons on it, iykyk ✨

✨ SYNOPSIS ✨

enum um_timetravel_ops {
    UM_TIMETRAVEL_ACK ,
    UM_TIMETRAVEL_START ,
    UM_TIMETRAVEL_REQUEST ,
    UM_TIMETRAVEL_WAIT ,
    UM_TIMETRAVEL_GET ,
    UM_TIMETRAVEL_UPDATE ,
    UM_TIMETRAVEL_RUN ,
    UM_TIMETRAVEL_FREE_UNTIL ,
    UM_TIMETRAVEL_GET_TOD ,
    UM_TIMETRAVEL_BROADCAST

};

💖 Constants 💖

So here's the whole cast of characters, one by one, no skips, no cap 🫶

• UM_TIMETRAVEL_ACK — the response (ACK) to any previous message. It usually doesn't carry any data in the 'time' field unless otherwise specified below. Note note note: while using shared memory there's no ACK for WAIT and RUN messages, and for more info you gotta see struct um_timetravel_schedshm 💀
• UM_TIMETRAVEL_START — initialize the connection. The time field contains an (arbitrary) ID so you can possibly tell the connections apart from each other 🦋
• UM_TIMETRAVEL_REQUEST — a request to run at the given time (host -> calendar) ⏰
• UM_TIMETRAVEL_WAIT — says "I'm waiting for the previously requested runtime", and new requests may be made while waiting (e.g. due to interrupts); the time field is ignored. The calendar must process this message and later send a UM_TIMETRAVEL_RUN message when the host can run again. (host -> calendar) 🧚
• UM_TIMETRAVEL_GET — return the current time from the calendar in the ACK message; the time in the request message is ignored (host -> calendar) ⭐
• UM_TIMETRAVEL_UPDATE — a time update to the calendar, and it must be sent e.g. before kicking an interrupt to another calendar (host -> calendar) 🔥
• UM_TIMETRAVEL_RUN — the run time request got granted, and the current time is in the time field (calendar -> host) 👑
• UM_TIMETRAVEL_FREE_UNTIL — enable free-running until the given time. This one's a message from the calendar telling the host it can freely do its own scheduling for anything before the indicated time. Heads up though: if a calendar sends this message once, the host may assume that it will also do so in the future, if it implements wraparound semantics for the time field. (calendar -> host) 🌸
• UM_TIMETRAVEL_GET_TOD — return time of day, typically used once at boot by the virtual machines to get a synchronized time from the simulation 🕰️
• UM_TIMETRAVEL_BROADCAST — send/receive a broadcast message. This message can be used to sync all components in the system with a single message: if the calendar gets the message, the calendar broadcasts the message to all components, and if a component receives it, it should act based on it, e.g. print a message to its log system. (calendar <-> host) 📣

🦋 SEE ALSO 🦋

• Kernel file ./include/uapi/linux/um_timetravel.h struct um_timetravel_msg(9)
• enum um_timetravel_shared_mem_fds(9)
• enum um_timetravel_start_ack(9)
• enum um_timetravel_schedshm_cap(9)
• enum um_timetravel_schedshm_flags(9)
• Time travel shared memory overview(9)
• union um_timetravel_schedshm_client(9)
• struct um_timetravel_schedshm(9)

okay that's the whole page, you ate that 💜 this one lives in ./include/uapi/linux and it's dated October 2026 — go forth and time travel responsibly, bestie, mwah 🍓💖