Kernel driving method under embedded real-time operating system

Abstract

The present application relates to a kind of kernel driving method under embedded real-time operating system, belong to embedded real-time operating system field.The method of the present application uses bus type driving framework to combine device tree mechanism, realizes the separation of driving code and hardware configuration information, to build kernel driving model;Wherein, bus type driving framework divides the driving of a certain device into two independent parts: bus driver and device driver;Device tree mechanism separates hardware configuration information from kernel code and driver program, and provides a standardized hardware description language to maintain hardware information, so that developers quickly understand hardware resource allocation;Through device tree mechanism, specific information of hardware device is dynamically transmitted to operating system, without using conditional compilation or static configuration hard coding.The present application realizes the standardization of hardware description, the generalization of driving code, to greatly improve the portability, maintainability and stability of embedded real-time operating system driving.

Description

Technical Field

[0001] This invention belongs to the field of embedded real-time operating systems, and specifically relates to a kernel driver method under an embedded real-time operating system. Background Technology

[0002] Traditional embedded real-time operating systems do not employ complex, dynamic bus-based driver frameworks. Unlike the "device-bus-driver" matching model, the core idea of ​​non-bus-based driver frameworks is decentralization and static binding. Their driver frameworks tend to use a static, pre-compiled "device table" model, lacking an intermediate "bus" abstraction layer. Drivers and devices are typically directly and explicitly associated during compilation or system initialization.

[0003] Non-bus-based driver management frameworks employ direct mapping or hard-coding. This means that the physical characteristics of all peripherals (such as register addresses, interrupt numbers, pin multiplexing configurations, and clock sources) are statically pre-compiled in the driver code or configuration files through macro definitions or data structures. There is no "plug-and-play" concept; the system is aware of the existence and location of all devices. Driver initialization functions are explicitly called directly by application developers, typically in the main function or system initialization tasks. Drivers are strongly dependent on specific chip models and lack a software abstraction layer.

[0004] In a non-bus-based driver management framework, some drivers use device tables or driver tables to provide a certain degree of centralized management capability. Essentially, the system maintains a static, constant array table, which is populated at compile time. Each entry in the table represents a physical device, containing its configuration parameters (such as base address, interrupt number, pin configuration) and pointers to its corresponding driver operation function set.

[0005] Non-bus-based driver frameworks sacrifice flexibility and portability for ultimate performance and determinism, which brings many drawbacks. These drawbacks become particularly prominent when projects are complex or require long-term maintenance.

[0006] The driver code is highly coupled with specific hardware platforms, and is filled with macros, address and register operations specific to certain chips, resulting in extremely poor hardware abstraction and portability. This leads to consequences such as extremely low code reusability, a large workload for porting, and hinders the development of the software ecosystem.

[0007] The lack of clear boundaries between drivers, device information, and applications, with the application layer aware of specific hardware details and drivers exhibiting high coupling and a rigid structure due to interdependence, leads to difficulties in maintenance, code testing, and high complexity in team collaboration.

[0008] All devices and their drivers are determined at compile time and initialized once at system startup, resulting in a lack of flexibility in driver management, causing system rigidity, and making it only suitable for scenarios with fixed functions and no hardware changes.

[0009] Because there is no unified device management core, each driver needs to implement some common functions, leading to code duplication. Specifically, this manifests as inconsistent initialization processes, with each driver potentially having different initialization function styles, return values, and parameters. I / O access interfaces are also implemented repeatedly. Locking mechanisms are inconsistent; some drivers use semaphores for mutual exclusion, while others disable interrupts, resulting in inconsistent coding styles and security. Although the overall framework appears simple, this increases code duplication, making the codebase bloated and prone to hard-to-find low-level bugs due to inconsistent implementations. Furthermore, developers need to learn the unique style of each driver, leading to a poor development experience.

[0010] The lack of standardized infrastructure makes development and debugging more reliant on engineers' personal experience, increasing the challenges of development and debugging. Specifically, when a driver malfunctions, it's difficult to quickly determine whether the problem lies with hardware, configuration, or the driver code itself. Driver usage relies excessively on documentation or comments rather than a unified API. Summary of the Invention

[0011] (a) Technical problems to be solved The technical problem this invention aims to solve is how to provide a kernel driver method under an embedded real-time operating system, in order to address the numerous problems caused by non-bus-type driver frameworks sacrificing flexibility and portability for ultimate performance and determinism.

[0012] (II) Technical Solution To address the aforementioned technical problems, this invention proposes a kernel driver method for embedded real-time operating systems. This method uses a bus-based driver framework combined with a device tree mechanism to separate driver code from hardware configuration information, thereby constructing a kernel driver model. The bus-based driver framework divides the driver of a device into two independent parts: bus driver and device driver. Each bus driver corresponds to a bus driver program, and each device driver corresponds to a device driver program. A bus driver is responsible for managing the low-level operations related to a specific bus, including enumerating devices on the bus, allocating and managing bus resources, providing bus access methods, and handling bus events. The bus driver is the parent node of a device child node, while the device driver is attached to the child node. When a device driver needs to access hardware resources, it calls the methods provided by the parent node bus driver to complete the resource allocation. The bus driver provides a unified resource allocation and configuration space access interface for all device drivers, so the device driver only needs to focus on the logic of the device itself. The device tree mechanism separates hardware configuration information from kernel code and drivers, and provides a standardized hardware description language to maintain hardware information, enabling developers to quickly understand hardware resource allocation; the device tree mechanism dynamically passes specific hardware device information to the operating system without the need for conditional compilation or static configuration hard coding.

[0013] (III) Beneficial Effects This invention proposes a kernel driver method for embedded real-time operating systems. This method standardizes hardware descriptions and generalizes driver code, thereby significantly improving the portability, maintainability, and stability of embedded real-time operating system drivers. This scheme allows a single kernel image to support multiple hardware platforms; for example, compiling a single Armv8 kernel image allows it to run normally on different boards. Similarly, it enables driver software to be compatible with multiple platforms and architectures; the same driver code can run on Arm, Aarch64, Loongarch, x86, and other architectures. The bus-based driver framework makes system initialization and configuration more standardized, and the system startup and driver loading processes clearer. By separating hardware descriptions from kernel code, the number of times driver code modifications and recompilations are reduced, lowering the risk of system crashes due to driver code errors and improving system stability and reliability. This invention builds a powerful, flexible, and standardized hardware abstraction layer for embedded real-time operating systems, enabling them to manage various hardware in a unified way, laying the foundation for cross-platform support and seamless hardware compatibility of embedded real-time operating systems. Attached Figure Description

[0014] Figure 1 This is a structural diagram of the bus-type driver framework of the present invention; Figure 2 This is a flowchart illustrating the process of loading drivers via a device tree in the bus-type driver framework of this invention. Detailed Implementation

[0015] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0016] The purpose of this invention is to provide a kernel driver method for embedded real-time operating systems. This method uses a bus-based driver framework combined with a device tree mechanism to separate driver code from hardware configuration information, thereby constructing a kernel driver model; wherein, The bus-based driver framework divides the driver of a device (e.g., a network card) into two independent parts: a bus driver and a device driver, thereby decoupling the driver from the hardware platform and standardizing the driver development process. Each bus driver corresponds to a bus driver program, and each device driver corresponds to a device driver program. A bus driver is responsible for managing the low-level operations associated with a specific bus (such as PCI, USB, I2C), including enumerating devices on the bus, allocating and managing bus resources (I / O ports, memory mapping, interrupt management, etc.), providing bus access methods, and handling bus events. A bus driver is typically the parent node of a device child node, while the device driver is attached to the child node.

[0017] When a device driver needs to access hardware resources (such as allocating memory or reading configuration space), it calls the methods provided by the parent bus driver to complete the resource allocation. A single bus driver can be shared by multiple different device drivers. The bus driver provides a unified interface for resource allocation and configuration space access to all device drivers, allowing them to focus solely on the device's own logic. The bus-based driver framework, through a software topology formed by several bus drivers, enables the operating system to isolate device hardware information from driver software, unify device discovery and management, abstract and encapsulate bus protocols, centralize resource management, promote code reuse, and reduce redundancy.

[0018] The introduction of the device tree mechanism solves the "hard-coding" problem for operating systems. It separates hardware configuration information from kernel code and drivers, and provides a standardized hardware description language to maintain hardware information, enabling developers to quickly understand hardware resource allocation. The device tree mechanism can dynamically pass specific hardware device information (such as memory addresses, interrupt numbers, etc.) to the operating system, eliminating the need for conditional compilation or static configuration hard-coding. This makes drivers simpler and more generic, and software maintenance easier.

[0019] Example 1: This invention proposes a bus-based driver framework for an embedded real-time operating system. It is a tree-like bus-based driver framework topology, with a hierarchical topology tree at its core. This topology tree is not merely a logical abstraction; it directly maps the actual connection relationships between physical hardware components. Every device in the system, whether physically present or virtually abstract, has a corresponding node in this topology tree. The construction principle of this topology tree is a parent-child relationship: each bus driver and device driver corresponds to one node. A parent node can have multiple child nodes, but each child node can only have one direct parent node. This relationship determines the device discovery order and resource management method.

[0020] The first level of the topology tree is the absolute root node, which is a virtual device called Nexus created by the kernel. This node is the starting point for building the bus-type driver framework during system startup.

[0021] The second layer of the topology tree is the bus layer, which includes various physical buses (such as PCI, USB, I2C) and bus bridges (such as PCI-to-PCI bridges). It is responsible for enumerating child nodes, resource mapping and conversion (converting I / O ports to memory addresses), and implementing bus interface methods (such as memory allocation, interrupt allocation, etc.).

[0022] The third level and below of the tree are the device driver layer, which are the leaf nodes of the tree structure, representing specific hardware entities (such as network cards, hard drives, etc.). Its topology accurately reflects the hardware connection method. The device driver identifies the hardware through the probe method, initializes the hardware through the attach method, and obtains allocated resources (memory, interrupts, etc.) from the parent node's bus or Nexus.

[0023] This tree structure is not merely a static description; it dynamically drives the core system operations. System initialization and device discovery proceed from the root node downwards according to the topology of the tree. The kernel creates the root node, and the root node driver detects and connects to its child device, Nexus. The Nexus driver begins its work, detecting buses on the bus-type driver framework. After discovering pci0 and calling its probe and attach methods, the pci0 driver begins enumerating the PCI bus. For each device discovered during enumeration, it calls the probe method of its driver; if a match is found, it calls the attach method to connect it to the topology tree. This process continues until all devices are discovered and initialized.

[0024] Resource management follows a tree-like topology, with functional devices requesting resources from the bottom up and allocating them from the top down. When a functional device needs resources (such as memory-mapped addresses or interrupt numbers), it sends a memory allocation request to its parent bus. If the parent bus is capable of allocating the resource, it processes it directly. If the resource exceeds its scope (e.g., requiring a system physical address), it continues to pass the request upwards until a parent bus capable of handling the request is reached. Nexus, as the platform bus, is ultimately responsible for allocating the system's physical resources to the bus driver, which then allocates them to specific functional devices. This bottom-up requesting and top-down granting mechanism ensures centralized and conflict-free resource allocation.

[0025] To use the device tree mechanism for hardware and software decoupling, it is necessary to link the bus-type driver framework, the kernel device tree module, and the custom device tree file. This invention adds a device tree bus driver, Ofwbus, to the bus-type driver framework. When the bus-type driver framework enumerates the device tree bus driver, it enters the specific implementation software of the device tree bus driver. The device tree bus driver relies on the interface provided by the kernel device tree module to parse the custom DTB binary file and obtain device node and hardware information. The custom DTB binary file is compiled from the custom device tree file.

[0026] To address the issue of hard-coding static driver configurations, a device tree module is designed for the operating system kernel. This module extracts hardware information from kernel and driver code, improving code versatility and portability. Encapsulated within the operating system kernel, the device tree module provides a series of function interfaces enabling the operating system and bus-based driver framework to parse binary DTB files and dynamically retrieve hardware configuration information. The bus-based driver framework includes a device tree bus layer. This bus relies on the interfaces provided by the kernel device tree module to parse custom DTB binary files and obtain the device nodes contained within them. After scanning the device nodes, the device tree bus retrieves the information contained within them (driver string name, memory address, interrupt number, etc.). The custom device tree file, which extracts hardware configuration information from the kernel code, acts as a "hardware information descriptor." It is a static hardware configuration file, existing as a .dts text file and a .dtb binary file. Custom device tree files don't care how the driver implements its functions; they are only responsible for describing hardware information, informing the kernel "what devices are on the board," "which bus the device is connected to," "what the device's address is," "which interrupt line the device uses," and "which clocks are needed," among other hardware information.

[0027] During the initialization phase of the bus-type driver framework, the tree topology enumerates child node drivers. When it encounters a device tree bus driver, it reads and parses the contents of the custom DTB binary file, identifying the node information within the custom device tree file. For each device node, the kernel extracts its key `compatible` attribute for driver matching. At this point, the bus-type driver framework holds a list of all devices parsed from the device tree file and mounted to specific physical buses. Simultaneously, it also holds a list of all drivers registered to various buses (such as PCI, USB, etc.). For each device without a bound driver, the bus-type driver framework uses the device's `compatible` attribute value to search the matching tables of all registered device drivers. When a matching entry for a device driver is found that matches the device's `compatible` string, the specific device and its driver are successfully matched. The bus-type driver framework then passes the structure maintaining the device hardware information to the driver software for initialization.

[0028] The bus-based driver framework operates as a highly automated, hierarchical process based on device discovery and driver matching. Its core begins during system initialization or bus driver loading, when the framework actively enumerates devices on its bus. For each discovered physical or virtual device, the framework creates a `device` structure object in the kernel and populates it with key hardware information. At this point, the device is in a "discovered but not yet driven" state. Next, the framework enters the crucial driver matching phase. The kernel iterates through all registered drivers suitable for that type and sequentially calls the `probe` method provided by each device driver (e.g., network card, hard drive). This method compares the device information with the device ID table supported internally by the device driver. If a match is found, the framework calls the `attach` method of the specific device driver to complete the hardware initialization settings. Throughout this process, the framework constructs a clearly hierarchical topology tree, from the root node to various buses and then to specific device nodes, intuitively reflecting the system's hardware topology.

[0029] Device driver unloading is implemented through the device driver's `detach` function, and is closely related to its parent bus driver. The unloading process is typically initiated by the bus driver (such as the PCI or USB bus driver software) and ultimately calls back to the specific device driver's `detach` method. When a user initiates unloading (e.g., by executing `kldunload` or hot-plugging a device), the bus driver iterates through the devices on the bus, finds and calls the device driver's `detach` method. Device unloading strictly follows the order of "releasing hardware resources first, then software structures" to complete the cleanup. After `detach` returns successfully, the bus driver is responsible for reclaiming the interrupts, memory mappings, and other resources allocated to that device.

[0030] By combining the device tree mechanism with a bus-based driver framework, the complexity of driver development is reduced, and hard-coding issues are resolved. This improves the portability and maintainability of driver software; hardware-related changes typically only require modification of the device tree file, without needing to rewrite the driver or recompile the kernel. The device tree mechanism frees driver software from tedious and volatile hardware details, allowing it to focus on implementing the device's functional logic, thereby significantly improving the hardware compatibility, stability, and development efficiency of the embedded real-time operating system.

[0031] Key points of this invention: The bus-based driver framework, combined with the device tree mechanism, separates driver code from hardware configuration information, thereby building a highly portable and easily maintainable modern kernel driver model. The core idea is that the driver itself only focuses on the general logic of "how to operate" the device, while the description of "whether the device exists" and "what its specific resources are" is handled by an independent mechanism. The device tree mechanism plays this role of "hardware describer." Through this approach, the same driver code can adapt to similar devices on different motherboards or platforms without hardcoding any hardware parameters, and the combination of these mechanisms achieves both driver generalization and high kernel portability.

[0032] To use the device tree mechanism for hardware and software decoupling, a bus-type driver framework, a kernel device tree module, and a custom device tree file must be linked. When the bus-type driver framework enumerates the device tree bus driver, it enters the driver software. The device tree bus driver relies on the interface provided by the kernel device tree module to parse the custom DTB binary file and obtain device nodes and hardware information. Developers need to write a DTS text file with standard device tree syntax for each different hardware board, compile it into a DTB type file using a DTC file, and store the DTB file in hexadecimal data at an address within the operating system. This address is then passed to the kernel device tree module to complete the parsing of the device tree device node content. Once the device tree bus receives this address, it can work with the interface provided by the operating system kernel device tree module to complete file parsing, extract the hardware information of the required device nodes, and complete the driver mounting.

[0033] Beneficial effects: This invention standardizes hardware descriptions and generalizes driver code, thereby significantly improving the portability, maintainability, and stability of embedded real-time operating system (RTOS) drivers. This solution allows a single kernel image to support multiple hardware platforms; for example, compiling a single Armv8 kernel image allows it to run normally on different boards. Similarly, it enables driver software to be compatible with multiple platforms and architectures, with the same driver code running compatiblely on Arm, Aarch64, Loongarch, and x86 architectures. The bus-based driver framework makes system initialization and configuration more standardized, and the system startup and driver loading processes clearer. By separating hardware descriptions from kernel code, the number of times driver code modifications and recompilations are reduced, lowering the risk of system crashes due to driver code errors and improving system stability and reliability. This invention builds a powerful, flexible, and standardized hardware abstraction layer for embedded ROS, enabling the ROS to manage various hardware in a unified way, laying the foundation for cross-platform support and seamless hardware compatibility of embedded ROS.

[0034] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A kernel driver method under an embedded real-time operating system, characterized in that, This method uses a bus-based driver framework combined with a device tree mechanism to separate driver code from hardware configuration information, thereby constructing a kernel driver model; among which, The bus-based driver framework divides the driver of a device into two independent parts: bus driver and device driver. Each bus driver corresponds to a bus driver program, and each device driver corresponds to a device driver program. A bus driver is responsible for managing the low-level operations related to a specific bus, including enumerating devices on the bus, allocating and managing bus resources, providing bus access methods, and handling bus events. The bus driver is the parent node of a device child node, while the device driver is attached to the child node. When a device driver needs to access hardware resources, it calls the methods provided by the parent node bus driver to complete the resource allocation. The bus driver provides a unified resource allocation and configuration space access interface for all device drivers, so the device driver only needs to focus on the logic of the device itself. The device tree mechanism separates hardware configuration information from kernel code and drivers, and provides a standardized hardware description language to maintain hardware information, enabling developers to quickly understand hardware resource allocation; the device tree mechanism dynamically passes specific hardware device information to the operating system without the need for conditional compilation or static configuration hard coding.

2. The kernel driver method under an embedded real-time operating system as described in claim 1, characterized in that, The bus-based driver framework uses a software topology formed by several bus drivers to achieve isolation between device hardware information and driver software, unified device discovery and management, abstraction and encapsulation of bus protocols, centralized resource management, promotion of code reuse and reduction of redundancy for the operating system.

3. The kernel driver method under an embedded real-time operating system as described in claim 1, characterized in that, The bus driver framework is a tree-like bus driver framework topology. Its core is a hierarchical topology tree, which is a logical abstraction and directly maps the real connection relationships between physical hardware. Every device in the system, whether physically existing or virtually abstract, has a corresponding node in this topology tree. The construction principle of the topology tree is a parent-child relationship. Each bus driver and device driver corresponds to a node. A parent node has multiple child nodes, but each child node can only have one direct parent node.

4. The kernel driver method under an embedded real-time operating system as described in claim 3, characterized in that, The first level of the topology tree is the absolute root node, which is a virtual device Nexus created by the kernel. This node is the starting point for building the bus-type driver framework when the system starts up. The second layer of the topology tree is the bus layer, which includes various physical buses and bus bridges. It is responsible for enumerating child nodes, resource mapping and conversion, and implementing bus interface methods. The third layer and below of the tree is the device driver layer, which is the leaf node of the tree structure and represents the specific hardware entity. Its topology truly reflects the connection method of the hardware. The device driver identifies the hardware through the probe method, initializes the hardware through the attach method, and obtains the allocated resources from the parent node bus or Nexus.

5. The kernel driver method under an embedded real-time operating system as described in claim 4, characterized in that, The system initialization and device discovery are performed from the root node down according to the topology of the topology tree. The kernel creates the root node, the root node driver detects and connects to its child device Nexus, the Nexus driver starts working, detects the bus on the bus-type driver framework, discovers pci0 and calls its probe and attach methods, the pci0 driver starts enumerating the PCI bus, and calls the probe method of each device discovered during the enumeration process. If a match is successful, the attach method is called to connect it to the topology tree. This process continues until all devices are discovered and initialized.

6. The kernel driver method under an embedded real-time operating system as described in claim 4, characterized in that, Resource management follows a tree-like topology, with functional devices issuing requests from the bottom up and granting resources from the top down. When a functional device needs resources, it sends a memory allocation request to its parent bus. If the parent bus is capable of allocating the resource, it will process it directly. If the resource is beyond its jurisdiction, the request will be passed up the chain until a parent bus capable of processing the request is reached. Nexus, as the platform bus, is ultimately responsible for granting the system's physical resources to the bus driver, which then allocates them to specific functional devices.

7. The kernel driver method under an embedded real-time operating system as described in any one of claims 1-6, characterized in that, The device tree mechanism decouples the bus-type driver framework, the kernel device tree module, and the custom device tree file through software and hardware decoupling. Specifically, a new device tree bus driver, Ofwbus, is added to the bus-type driver framework. When the bus-type driver framework enumerates the device tree bus driver, it enters the specific implementation software of the device tree bus driver. The device tree bus driver relies on the interface provided by the kernel device tree module to parse the custom DTB binary file and obtain device node and hardware information. The custom DTB binary file is compiled from the custom device tree file.

8. The kernel driver method under an embedded real-time operating system as described in claim 7, characterized in that, The device tree module is encapsulated within the operating system kernel. This module provides a series of function interfaces that enable the operating system and bus-based driver framework to parse binary DTB files and dynamically retrieve hardware configuration information from them. The bus-based driver framework includes a device tree bus layer. This bus relies on the interfaces provided by the kernel device tree module to parse custom DTB binary files and obtain the device nodes contained within them. After scanning the device nodes, the device tree bus retrieves the information contained within them. The custom device tree file extracts the hardware configuration information from the kernel code and is a static hardware configuration file, existing as a .dts text file and a .dtb binary file. The custom device tree file does not concern itself with how the driver implements its functionality; it only describes the hardware information and informs the kernel of this information.

9. The kernel driver method under an embedded real-time operating system as described in claim 7, characterized in that, During the initialization phase of the bus-type driver framework, the tree topology enumerates child node drivers. When a device tree bus driver is enumerated, the custom DTB binary file is read and parsed to identify the node information in the custom device tree file. For each device node, the kernel extracts its key compatible attribute for driver matching. At this time, the bus-type driver framework holds a list of all devices parsed from the device tree file and mounted to specific physical buses. Simultaneously, the bus-type driver framework also holds a list of all drivers registered to each bus. For each device without a bound driver, the bus-type driver framework uses the device's compatible attribute value to search in the matching tables of all registered device drivers. When a matching entry for a device driver is found that matches the device's compatible string, the specific device and the specific device driver are successfully matched. The bus-type driver framework then passes the structure maintaining the device hardware information to the driver software for initialization.

10. The kernel driver method under an embedded real-time operating system as described in claim 7, characterized in that, The bus-based driver framework is a highly automated, hierarchical process based on device discovery and driver matching. During system initialization or bus driver loading, the bus-based driver framework actively enumerates the devices on its bus. For each discovered physical or virtual device, the bus-based driver framework creates a device structure object in the kernel and populates it with key hardware information. At this point, the device is in a "discovered but not yet driven" state. Next, the bus-based driver framework enters the crucial driver matching stage. The kernel iterates through all registered drivers applicable to this type and sequentially calls the probe method provided by each device driver. This method compares the device information with the device ID table supported internally by the device driver. If a match is found, the bus-based driver framework calls the attach method of the specific device driver to complete the hardware initialization settings. Throughout this process, the bus-based driver framework constructs a clearly hierarchical topology tree, from the root node to various buses and then to specific device nodes, intuitively reflecting the system's hardware topology. Device driver unloading is implemented through the device driver's detach function, which is closely related to its parent bus driver. The unloading process is initiated by the bus driver and eventually calls back to the detach method of the specific device driver. When the user initiates unloading, the bus driver will traverse the devices under the bus, find and call the detach method of the device driver. Device unloading strictly follows the order of "releasing hardware resources first, then releasing software structures" to complete the cleanup work. After detach returns successfully, the bus driver is responsible for reclaiming the interrupt and memory mapping resources allocated to the device.

Images