Something interesting recently emerged on the Linux kernel front—a new patch series titled “Live Update Orchestrator,” authored by Google’s engineer Pasha Tatashin and built on top of an earlier set of patches commonly referred to as the KHO v5 patch series.
It aims to enable smooth kernel updates—referred to as “Live Update”—so that certain devices remain fully operational during the transition from an old kernel to a new one.
Essentially, the innovative Live Update Orchestrator (LUO) subsystem intends to minimize system downtime by preserving device states across a reboot, particularly benefiting dynamic cloud environments where even minor disruptions can be unwelcome.
According to the developers, this approach uses a state-machine mechanism to orchestrate the transition. The LUO subsystem tracks progress through several states—“normal,” “prepared,” and “updated”—and ties them together through callback APIs.
These callbacks allow other kernel subsystems (e.g., KVM, IOMMU, interrupts, the new dev_liveupdate device layer, and memory management) to integrate seamlessly into the live update workflow.
Furthermore, the system can be controlled via a sysfs interface at “/sys/kernel/liveupdate/{state, prepare, finish}.” When it is used, the Live Update sequence unfolds as follows:
- normal: The kernel runs as usual, with no live update taking place.
- prepare: Writing “1” to “/sys/kernel/liveupdate/prepare” triggers the
LIVEUPDATE_PREPAREcallback, moving subsystems into a transitional “prepared” state. - updated: Once the new kernel takes over, the system enters the “updated” state, meaning devices and subsystems are resuming functionality.
- finish: Writing to “/sys/kernel/liveupdate/finish” executes a final transition back to “normal,” invoking the
LIVEUPDATE_FINISHcallback and restoring complete operational status.
However, such a major change to the Linux kernel cannot happen just like that. Greg Kroah-Hartman, a major figure in its development, has expressed reservations and called for more substantial evidence of LUO’s feasibility.
Specifically, he emphasizes the need for “real, actual, working patches for at least three bus subsystems” before he and other maintainers will consider a serious review.
As you can imagine, I have “thoughts” about all of this being added to the driver core. But, before I go off on that, I want to see some real, actual, working, patches for at least 3 bus subsystems that correctly implement this before I even consider reviewing this.
Moreover, in his answer on the Linux kernel development mailing list, he underscores the importance of well-developed user-space tools capable of managing the potentially large number of devices involved in any live update scenario.
In other words, there’s still a long way to go before LUO functionality makes its way into the Linux kernel—if it ever does. We’ll keep an eye on things, and, as always, we’ll keep you posted on any new developments. For more information, see the announcement itself here.
