Unified Driver Architecture for Multi-OS Hardware Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current attempts to run multiple operating systems on mobile devices are cumbersome, suffer from poor performance, and require separate driver development, rebooting, and heavy memory usage, limiting user experience and increasing development costs.
Innovation Solution
A method and system that allows multiple operating systems to access hardware resources by running a kernel and driver within the primary operating system, providing access to hardware resources for both primary and secondary operating system applications through a shared driver within the kernel, enabling seamless switching without rebooting.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If separate driver development is performed for each operating system, then hardware compatibility is achieved, but development time and costs increase
Solution Approach 1:
The patent implements a universal driver architecture where a single driver developed for the primary operating system can serve multiple operating systems through a confluence layer. The driver is designed with abstracted hardware access interfaces that can be invoked by different OS kernels, eliminating the need to develop separate drivers for each OS while maintaining full hardware compatibility.
Solution Approach 2:
The confluence layer acts as an intermediary between multiple operating systems and the shared driver. It provides a standardized interface that allows different OS kernels to access the same driver through common protocols, translating OS-specific requests into universal driver commands, thus enabling one driver to serve multiple purposes across different operating systems.
2Adaptability or versatility
If multiple operating systems are run with separate kernels, then OS functionality is achieved, but memory usage increases
Solution Approach 1:
The patent merges multiple operating system kernels into a shared kernel space where they can coexist and access common resources. Instead of allocating separate memory spaces for each OS kernel, the system implements a unified kernel architecture with shared data structures, device drivers, and hardware abstraction layers, significantly reducing overall memory consumption while maintaining full OS functionality.
Solution Approach 2:
The shared kernel is designed with universal components that can serve multiple operating systems simultaneously. Hardware drivers, device controllers, and system services are implemented as shared resources that can be accessed by different OS instances, eliminating redundant memory allocations and enabling efficient multi-OS operation with reduced memory footprint.
3Reliability
If separate driver instances are created for each operating system, then hardware access is achieved, but device complexity increases
Solution Approach 1:
The driver architecture is segmented into distinct functional layers: a universal driver core that handles hardware communication, and OS-specific interface layers that provide operating system abstraction. This segmentation allows the complex hardware access logic to be isolated in the universal driver while presenting simplified interfaces to each operating system, reducing overall system complexity while maintaining reliable hardware access.
Solution Approach 2:
The confluence layer serves as an intermediary that manages driver instances and coordinates access between multiple operating systems and shared hardware resources. It implements a standardized interface protocol that simplifies the interaction between diverse OS kernels and the underlying driver architecture, reducing complexity by providing a uniform access mechanism rather than requiring each OS to implement its own direct driver interfaces.
Data Source
AI summary
Applications of multiple operating systems are provided with access to hardware resources within a mobile device. An application associated with a primary operating system is provided with access to at least some of the hardware resources via a driver running within a kernel of the primary operating system. An application associated with a secondary operating system is also provided with access to at least some of the hardware resources via the driver running within the kernel of the primary operating system.