Embedded Application Upgrade via Shared Memory State Transfer
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for upgrading single partition kernel-based embedded applications often result in significant 'blackout time' due to disruptions in connected TCP clients, as they require sequential updates that interrupt service.
Innovation Solution
A method involving an orchestrator that coordinates a second core to load and execute a new code load in parallel with the old one, saving and transferring process states and TCP connection states through shared memory, allowing for concurrent updates without disrupting clients.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If sequential update method is used for single partition kernel-based embedded applications, then system stability is maintained, but blackout time increases significantly
Solution Approach 1:
The system divides the kernel update process into two separate partitions: partition 0 containing the old kernel and partition 1 containing the new kernel. Both partitions can coexist in memory simultaneously, allowing the system to switch between them without interrupting service. This segmentation enables parallel operation of old and new code loads, eliminating sequential update bottlenecks and reducing blackout time while maintaining system stability through partition switching.
2Ease of manufacture
If traditional update method is used, then simplicity of implementation is maintained, but service continuity is disrupted
Solution Approach 1:
The system performs preliminary actions by loading the new kernel into partition 1 before the old kernel in partition 0 is terminated. The new kernel is initialized and prepared in advance, with its network stack and drivers loaded and configured. This preliminary preparation allows the system to switch partitions seamlessly without service interruption, as the new kernel is already ready to take over immediately when the old kernel exits.
3Loss of time
If concurrent execution of old and new code loads is implemented, then blackout time is minimized, but resource management complexity increases
Solution Approach 1:
The system extracts and isolates the kernel code loads into separate memory partitions with distinct management. Partition 0 and partition 1 are independently managed with separate kernel instances, allowing concurrent execution without interference. The orchestrator extracts and manages the lifecycle of each partition independently, simplifying resource management despite concurrent operation by treating each partition as a separate, self-contained unit.
4Productivity
If process state and TCP connection state are transferred through shared memory, then service disruption is avoided, but data transfer reliability requirements increase
Solution Approach 1:
The system introduces shared memory as an intermediary mechanism for transferring process state and TCP connection state between partition 0 and partition 1. The shared memory region acts as a buffer that allows the new kernel to acquire the current state without direct interference with the running old kernel. This intermediary approach enables seamless state transfer and maintains service continuity, as the transfer occurs through a dedicated communication channel that does not disrupt the running system.
Data Source
AI summary
Embodiments describe an approach for improving for improving application upgrade by minimizing blackout time for a single partition kernel. Embodiments send a command to a second core to load a new code load into a second portion of a memory and to execute the new code load, and instruct an old code load, executing on a first core, to save a process state and TCP connection state in a shared memory. Additionally, embodiments, instruct the new code load to read the process state and the TCP connection state from the shared memory, receive a notification from the new code load that the new code load is active and processing client requests, and instruct the old code load to terminate and remove the old code load from a first portion of the memory.