Kernel Device Module Live Update via Proxy Mediator
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In computing environments, particularly for cloud service providers, updating kernel device modules while maintaining minimal disruption to running systems is challenging due to issues like lost state and interference with user sessions, as existing methods fail to manage the transition between old and new modules effectively.
Innovation Solution
A proxy module is introduced to manage the registration and communication between different versions of kernel device modules, allowing for a seamless transfer of control without disrupting ongoing user sessions by maintaining necessary state information and handling IOCTL and sysfs calls, thus enabling a live update of kernel device modules.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a running kernel device module is replaced by unloading and reloading a new module, then the module can be updated with bug fixes or security patches, but the state managed by the old module is lost and user sessions are disrupted
Solution Approach 1:
A proxy module is introduced as an intermediary between the old and new device modules. The proxy module maintains the device state during the transition period and facilitates communication between the old module, new module, and device. This mediator ensures state information is preserved and transferred without loss while enabling smooth module replacement.
Solution Approach 2:
The proxy module is loaded and initialized before the new device module is fully replaced. It preliminarily establishes state management capabilities and communication channels, then gradually transfers state information to the new module. This preliminary preparation prevents state loss by ensuring the proxy is ready to capture and transfer state before the old module unloads.
2Productivity
If the old kernel device module is unloaded completely, then the new module can take control, but there is a period where no driver manages the device causing lost state
Solution Approach 1:
The proxy module ensures continuous device management during the transition period. Instead of a complete gap where no driver manages the device, the proxy module maintains ongoing management responsibilities including state tracking, IOCTL call handling, and device registration. This continuity eliminates the lost state period while enabling fast module replacement.
Solution Approach 2:
The proxy module serves as a bridge that remains active between the old and new modules during replacement. It continues to manage device operations while the new module is being loaded and initialized, ensuring no management gap occurs. The intermediary role allows overlapping operation phases that eliminate dead time in device management.
3Reliability
If user sessions are interrupted to install updated kernel device modules, then the updated module can be properly installed, but cloud service providers cannot maintain live production environments with thousands of hosts
Solution Approach 1:
The proxy module acts as an intermediary that enables module updates without interrupting user sessions. It maintains device state and manages transitions in the background, allowing the system to perform updates while remaining operational. This mediator makes live environment compatibility possible by abstracting the complexity of module replacement from user-visible operations.
Solution Approach 2:
The system performs self-service module updates without requiring user intervention or session interruption. The proxy module automatically manages the replacement process, transferring state information and handling device operations transparently. This self-service capability allows cloud service providers to update modules live across thousands of hosts without disrupting user sessions.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Systems, apparatuses, and methods for implementing live device driver updates are disclosed. When a processor loads a given version of a device driver, the given version registers with a proxy module rather than registering with the operating system. If a previous version of the device driver is already running, the proxy module provides the given version with a pointer to the previous version. The given version uses the pointer to retrieve static data from the previous version. After the previous version is quiesced, the given version retrieves transient data from the previous version and then takes over as the running version of the device driver. Subsequent versions of the device driver are able to replace previous versions in a similar manner. Also, previous versions of the device driver are able to replace subsequent versions in a similar manner in the case of downgrading.