CN113268275B - Hardware equipment driving system based on microkernel and driving method thereof - Google Patents
Hardware equipment driving system based on microkernel and driving method thereof Download PDFInfo
- Publication number
- CN113268275B CN113268275B CN202110810358.0A CN202110810358A CN113268275B CN 113268275 B CN113268275 B CN 113268275B CN 202110810358 A CN202110810358 A CN 202110810358A CN 113268275 B CN113268275 B CN 113268275B
- Authority
- CN
- China
- Prior art keywords
- equipment
- driver
- drive
- interface
- calling
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a hardware equipment driving system based on microkernel and a driving method thereof, wherein the system comprises a bottom driving layer, an equipment abstraction layer, a consistency API layer, a remote procedure calling layer and an equipment manager; the bottom driving layer is used for realizing various operations on the equipment; the device abstraction layer is used for providing an encapsulation interface; the consistency API layer is used for carrying out secondary packaging on the packaging interface; the remote procedure calling layer is used for carrying out remote procedure calling communication between the packaging interface and the user interface; the device manager is used for managing device information, managing device operation information and managing device drivers. The hardware device driving method greatly reduces the complexity of the driver code, improves the readability of the driver code, reduces the driver development time of the driver developer, and finally achieves the effect of reducing the research and development cost.
Description
Technical Field
The invention belongs to the technical field of equipment driving, and particularly relates to a hardware equipment driving system based on a microkernel and a driving method thereof.
Background
In Linux, different drive implementations are designed for different types of equipment, and the drive implementation is realized by extracting the same parts from similar hardware drives of different manufacturers and reserving interfaces for specific drive development engineers for implementation, so that the drive standardization is realized. Some systems for uniformly managing system resources are also designed in the kernel, and the systems enable the kernel to uniformly coordinate and distribute the resources used among the drivers, so that the stable and healthy operation of the system is ensured.
As can be seen from the above description, the driver framework of the kernel is the specific interface functions and the specific data structures provided by the driver framework. The drivers of the Linux are integrated in the kernel and are uniformly managed by the kernel. The Linux kernel uses a platform bus mechanism for managing and registering drivers, and the platform bus is a virtual bus and not a physical bus. The two most important structures of a platform bus are platform _ device and platform _ driver. The two structures respectively manage a driving device and a driving bus, the platform _ device structure comprises information of a device name, a device ID, the number of resource structures, device resources and the like, and the resource structure stores the most important device resource information comprising a resource starting address, a resource ending address, a resource type and the like; the platform _ driver structure includes a device probe function called when registering the platform device, a delete function called when deregistering the platform device, a device driver structure, a list of devices supported by the device driver, and the like.
The bus-driver-device framework of Linux is a commonly used driving framework at present. The physical basis of the bus-driver-device framework of the Linux is that the external equipment communicates with the CPU through a bus. The kernel is responsible for realizing bus specification and equipment management (including equipment detection, drive binding and the like) parts in the framework, and the driver is responsible for registering own drive to realize read-write control of the equipment. Drivers that operate in a bus-driver-device fashion are generally divided into two levels: bus subsystem, drive module. The bus-driver-device driver framework does not define the specific implementation mode of each specific driver of Linux, namely the mode of code design and organization. The driver part of the Linux driver framework, namely the framework of the driver part, is defined under the driver/base directory of the Linux kernel code, the Linux drivers all have respective architecture modes, various architectures of the Linux drivers are called as 'subsystems', and the codes of the subsystems are located under the driver/base directory of the kernel. The existing bus-driver-device driving framework of the Linux kernel has the following defects: firstly, the driver module is organized together with kernel codes, so that the transportability and the safety are low, and if the driver module crashes, the kernel is influenced; secondly, various types of driving codes are organized in the kernel in different modes, so that the code complexity is higher, and the difficulty and the cost of development and transplantation are increased.
Disclosure of Invention
The invention aims to solve the problems of complexity and low safety of the existing driving framework and provides a hardware device driving system based on a microkernel and a driving method thereof.
The technical scheme of the invention is as follows: a hardware device driving system based on microkernel includes a bottom driving layer, a device abstraction layer, a consistency API layer, a remote procedure calling layer and a device manager;
the bottom driving layer is used for realizing various operations on the equipment;
the device abstraction layer is used for providing an encapsulation interface of the bottom layer driving operation;
the consistency API layer is used for carrying out secondary packaging on a packaging interface of the equipment abstraction layer and providing a user interface;
the remote procedure calling layer is used for carrying out remote procedure calling communication between a packaging interface of the equipment abstraction layer and a user interface of the consistency API layer, and calling of a user to equipment drive is realized through the remote procedure calling communication between the client and the server;
the device manager is used for managing device information, managing device operation information and managing device drivers.
Furthermore, the packaging interface of the device abstraction layer comprises a drive initialization interface, a device drive binding interface, a device drive unbinding interface, an opening device interface, a closing device interface, a read-write transmission interface, a write interface, a read interface and a control interface;
the user interface of the consistency API layer comprises an equipment binding driving interface, an equipment unbinding driving interface, an equipment opening interface, an equipment closing interface, a reading and writing equipment interface, a reading equipment interface and an equipment control interface.
Further, in the device manager, the device information is used for describing the hardware device driving system management device; the equipment operation information is used for managing the pre-initialization, the life cycle and the equipment maintenance of the equipment through an equipment manager; the device driver comprises driver loading, driver registration, driver logout and driver unloading;
the driver loading is used for loading a driver ELF file of the equipment; driver registration for associating drivers with devices; the driver logout is used for canceling the association between the driver and the equipment; the driver offload is used to remove the ELF process from the memory;
the drive loading comprises static loading and dynamic loading; the static loading is used for calling a drive entry function loading drive to run in the starting process of the hardware equipment drive system; the dynamic loading is used for driving and loading after the hardware device driving system is started, specifically after the devmgr process is started.
The invention has the beneficial effects that: the hardware device driving system simplifies the driving abstract layer, so that the hardware driving has lower resource consumption, better maintainability, conciseness, reusability and expandability; the code amount required by the driver transplanting and developing work is reduced, so that the research and development cost of the driver transplanting and developing work is reduced; the decoupling of the driver and the kernel is completed, so that the driver module has stronger flexibility and portability, the stability of the kernel is ensured, and the normal operation of the system is ensured when the driver layer has the problems of accidental collapse and the like.
Based on the system, the invention also provides a hardware device driving method based on the microkernel, which comprises the following steps:
s1: calling and initializing a device driver;
s2: classifying the equipment, and starting an equipment driver and the equipment by utilizing an equipment manager;
s3: performing equipment registration and equipment drive registration based on the started equipment drive and equipment;
s4: calling device drivers in different driver processes;
s5: and in the calling process, judging whether the equipment is disconnected with the equipment driver or not, if so, performing drive logout, and otherwise, continuing equipment driver calling among different drive processes.
Further, in step S1, the specific method for calling the device driver is as follows: acquiring an equipment instance of corresponding equipment from the equipment drive, and performing read-write operation on the equipment instance to finish calling;
initializing the device driver, wherein the initializing device driver comprises an initializing bus device driver and an initializing specific device driver; the specific method for initializing the bus equipment drive comprises the following steps: starting a bus equipment driver, initiating driver registration to an equipment manager, associating the adapted equipment with the bus equipment driver, and informing the bus equipment driver to initialize by using the equipment manager;
the specific method for initializing the specific device driver comprises the following steps: starting a specific device driver, initiating driver registration to a device manager, associating the adapted device with the specific device driver, and notifying the specific device driver to initialize by using the device manager.
Further, in step S2, the devices are classified into four categories, which are: system key equipment, bus equipment, static equipment and dynamic equipment;
the specific method for starting the static equipment comprises the following steps: initiating a binding operation by using an equipment manager, judging whether the current drive supports the equipment or not by using an equipment drive, if so, binding an equipment identity identifier and an equipment drive identifier to complete the starting of the static equipment, and if not, continuously traversing a drive list; if the traversed drive list has a drive supporting the equipment, performing binding operation, otherwise waiting for next triggering of the binding operation;
the specific method for starting the dynamic equipment comprises the following steps: and calling the equipment monitoring interface by using the equipment manager to monitor whether the new equipment is accessed into the equipment driver, calling the control interface by using the equipment manager to receive the equipment information of the new equipment if the new equipment is accessed into the equipment driver, automatically matching the adaptive equipment driver, and starting the equipment.
Further, the device registration in step S3 includes static device registration and dynamic device registration, and the registration method of the static device is as follows: analyzing the equipment tree by utilizing the equipment driver to obtain equipment information of the static equipment, initiating a static equipment registration application, returning the static equipment identity identification if the registration is successful, and otherwise, initiating the static equipment registration application again until the static equipment registration is successful;
in step S3, the method for registering a dynamic device includes the following substeps:
a31: analyzing the equipment tree by utilizing equipment driving, and generating and traversing an equipment list;
a32: judging whether the bus successfully matches the device driver with the device, if so, entering the step A33, otherwise, after sleeping within the set time, returning to the step A31;
a33: traversing the drive list, judging whether the equipment drive is loaded successfully or not, if so, applying an equipment drive identity and an equipment identity to the equipment number pool, and entering the step A34, otherwise, sleeping within a set time and returning to the step A31;
a34: creating a daemon process, and monitoring and reporting new dynamic equipment entering an equipment driver in the daemon process;
a35: applying for registering new dynamic equipment;
statically defined devices enter the registration process at system start-up. The statically defined equipment refers to static equipment of a system which is well defined in an equipment tree, firstly the system analyzes the equipment tree to obtain relevant information of the static equipment, then application for registration of the static equipment is initiated, if the registration is successful, an equipment ID is returned, and if the registration is failed, the static equipment is applied again until the registration application of the static equipment is successful.
In step S3, the device driver registration methods of the static device and the dynamic device are the same, and both include the following substeps:
b31: analyzing the equipment tree by utilizing equipment driving, and generating and traversing an equipment list;
b32: judging whether the equipment is successfully matched with the equipment driver or not, if so, entering a step B33, otherwise, sleeping within a set time and returning to the step B31;
b33: traversing the drive list, judging whether the device driver and the device are successfully matched with the drive ELF file, if so, entering a step B34, otherwise, sleeping within a set time and returning to the step B31;
b34: and loading the driver ELF file, setting a matching success identifier, applying for an equipment driver identity from the driver number pool, and finishing equipment driver registration.
Further, step S4 includes the following sub-steps:
s41: initiating a request for calling a drive process B by using a drive process A;
s42: based on the calling request, calling an equipment management application programming interface to inquire equipment information and equipment driving information and returning the equipment information and the equipment driving information to the A driving process;
s43: and calling the bottom drive layer, the equipment abstraction layer and the consistency API layer of the simulation drive type API drive B drive process, returning to the A drive process, and completing the calling among different drive processes.
Further, the specific process of performing logout in step S5 is as follows: the method comprises the steps of sequentially applying for equipment logout, applying for equipment logout information, releasing equipment resources, unbinding the equipment and an equipment driver, logout of an equipment identity, logout of an equipment driver identity and release of the equipment driver resources.
The invention has the beneficial effects that:
(1) for developers, the driving framework performs uniform processing on all drivers, and all driver coding designs are based on the same framework structure and the same abstract layer and user layer interface, so that the complexity of driver coding is greatly reduced, the readability of driver codes is improved, the driver development time of the driver developers is reduced, and the effect of reducing the research and development cost is finally achieved.
(2) For the user, the hardware equipment driving method of the invention has simpler interface facing the user and reduces the complexity of calling between the drivers.
(3) The hardware device driving method of the present invention can be transplanted and applied to hardware platforms of all architectures, including but not limited to: x86, ARM, Mips, Alpha, PowerPC, and UltraSPARC, among others.
Drawings
FIG. 1 is a block diagram of a hardware device driver system;
FIG. 2 is a flow chart of a method for driving a hardware device;
FIG. 3 is a flow diagram of statically defined device startup;
FIG. 4 is a flow diagram of a dynamically generated device boot-up;
FIG. 5 is a statically defined device registration flow diagram implemented by a hardware driven method;
FIG. 6 is a flow diagram of a dynamically generated device registration;
FIG. 7 is a flowchart illustrating driver registration for static devices and dynamic devices;
FIG. 8 is a flow chart of inter-driver calls;
FIG. 9 is a call flow when inter-driver calls are performed using inter-driver call interfaces defined by the Commute class;
FIG. 10 is a driver usage flow diagram in which the usage flow of the driver involves a user, devmgr, and driver processes;
fig. 11 is a flow diagram of dynamic device deregistration.
Detailed Description
The embodiments of the present invention will be further described with reference to the accompanying drawings.
Before describing specific embodiments of the present invention, in order to make the solution of the present invention more clear and complete, the definitions of the abbreviations and key terms appearing in the present invention will be explained first:
linux: developed by Linus, widely used throughout the world, and supporting a variety of CPU, multi-user, multi-tasking operating systems.
API: application Program Interface, Application programming Interface.
Microkernel: micro kernel, a compact form of kernel, is designed to increase portability in a small memory space, providing a modular design to allow users to install different interfaces.
RPC: remote Procedure Call.
ELF: executable and Linkable Format, a Unix-like operating system binary file standard Format.
rpc _ call () function: the remote procedure calls a call function for establishing a remote procedure call.
Ginseng introduction: generic description, representing incoming parameters.
rpc _ reply () function: the remote procedure calls a response function.
rpc _ reply _ data () function: the remote procedure calls a data response function.
Simulating a driver API: for serializing the drive information.
As shown in fig. 1, the present invention provides a hardware device driver system based on microkernel, which includes a bottom driver layer, a device abstraction layer, a consistency API layer, a remote procedure call layer and a device manager;
the bottom driving layer is used for realizing various operations on the equipment;
the device abstraction layer is used for providing an encapsulation interface of the bottom layer driving operation;
the consistency API layer is used for carrying out secondary packaging on a packaging interface of the equipment abstraction layer and providing a user interface;
the remote procedure calling layer is used for carrying out remote procedure calling communication between a packaging interface of the equipment abstraction layer and a user interface of the consistency API layer, and calling of a user to equipment drive is realized through the remote procedure calling communication between the client and the server;
the device manager is used for managing device information, managing device operation information and managing device drivers.
Firstly, writing a bottom layer driving function facing hardware operation by using C language; specifically, the C language is used to implement operations of various drivers on various hardware registers, the implementation of the bottom driver needs to refer to hardware manuals of various hardware, and functions that different hardware needs to implement are different. The encoding of the first step is the encoding of the specific driver _ specific _ api. For the encoding of a specific drive, a specific device class is defined. The concrete device class can realize the writing of the whole driver only by realizing the driver _ specific _ api defined by the abstract driver class. The remaining lengthy business logic processing is completed in the device abstraction layer described in step two of S2, also referred to as the middle layer, which exposes only a small number of interfaces to the concrete driver classes for adapting to different hardware.
And secondly, writing a packaging interface for operating the bottom-layer drive hardware by using C + +, which is called writing a device abstraction layer API. The packaging interfaces are defined uniformly, the difference between the implementation of bottom layer drivers does not need to be considered, and the same packaging interfaces are used by various drivers, including a driver initialization interface, a device driver binding interface, a device driver unbinding interface, a device opening interface, a device closing interface, a read-write transmission interface, a write interface, a read interface and a control interface. The different drivers, if specifically functional, may be encapsulated into the control interface. The device abstraction layer code written in the second step, whose execution logic contains the encapsulation of the device abstraction layer API to the consistency API used by the user, and implements some general functions through the device abstraction layer API, is exposed to the IOCTL interface in the consistency API used by the user (e.g., an application may need to control the USB controller to scan for a newly suspended device through the device IOCTL interface). Based on the design, the purpose that different hardware drivers use uniform packaging interfaces can be achieved, the packaging interfaces achieve the goal of abstracting and unifying functions achieved by the device drivers, the difference between different hardware drivers is reduced, and the driving framework is simplified. Meanwhile, the API of the device abstraction layer provided in the second step unifies the code writing logic and the code building framework of each driver, each driver code is packaged by using a consistent interface, and does not distinguish character devices, block devices and network devices, and does not distinguish a USB master device driver and a USB slave device driver in a design level and a calling level, and various hardware driver flattening methods are used for coding, so that various hardware can be conveniently called mutually.
And thirdly, writing a user interface facing the user by using C + +, wherein the user interface is called writing user-facing consistency API and is obtained by further packaging the function interface in the second step, and the consistency API written in the third step provides an equipment binding driving interface, an equipment unbinding driving interface, an equipment opening interface, an equipment closing interface, a read-write equipment interface, a write-write equipment interface, a read-write equipment interface, an equipment control interface and the like for the user to use. And other processes call the interface realized by the third step through IPC, so that the function of the driving module is called.
And fourthly, coding to realize RPC calling, and organizing communication between the user interface in S3 and the device abstraction layer interface in S2 by using the RPC calling.
And fifthly, coding to realize a device manager, and managing the device information, the device operation information and the relationship between the device and the driver by using the device manager.
The coding operation from the first step to the third step realizes hardware-driven coding hierarchy, and follows the following three basic principles:
(1) the driver module is re-enterable (the same driver module may manage multiple device instances): when the consistency API used by the user is called, the IPC carries information capable of identifying the device instance;
(2) the same device instance is typically not reentrant: in most cases it is necessary to provide a locking mechanism to ensure that only one device module is operating a device instance at the same time;
(3) the device instances are uniformly managed by a device manager (devmgr) that should listen to the event messages of the driver modules (through the IOCTL interface, i.e., the control interface) to learn about the creation and destruction of the device.
The drivers are divided into three abstract classes in the code implementation:
(1) class driver base (class driver _ base); the base driver type provides a uniform calling interface (i.e. driver _ ops) upwards, which is the entry type of the driver process. The basic class registers an interface called externally by calling syscall, and calls the interface by calling a corresponding method of a driver after the external call comes.
(2) Abstract device class (class driver _ abstract); the way in which the base class is invoked is essentially implemented by the abstract device (driver _ abstract). The abstract class device only realizes the uniform operation steps of a certain class of drivers, but does not realize the specific detailed operation of the drivers. Such as: when the abstract driver class corresponds to an abstract class of the USB device, only the functions of the USB protocol stack (device enumeration and device mount) are provided, and the initialization method and the read/write method for the USB controller are not implemented. The driver abstract class defines a set of underlying methods (driver _ sepcific _ api) to be implemented by the more underlying concrete driver classes.
(3) Specific drive (driver _ specific _ api): the concrete device class can realize the writing of the whole driver only by realizing the driver _ specific _ api defined by the abstract driver class. The drive framework tries to complete the lengthy business logic processing in the middle layer (abstract device class), and only a small number of interfaces are exposed to the concrete drive class for adapting to different hardware.
The three abstract concrete functions of the driver can be summarized by the above description as follows: the basic class (driver _ base) is used for providing a consistency API for the outside, the service processing is realized in an intermediate layer (abstract driver class, namely driver _ abstract driver), and the specific driver class realizes a defined driver _ specific _ API interface to realize the operation of the hardware IO.
And in the fourth step, the code realizes RPC (remote procedure call), the IPC call relation between the user program and the drive component needs to be solved, and the user calls the equipment abstraction layer interface defined in the second step through the user unified interface defined in the third step.
In the embodiment of the invention, the packaging interface of the device abstraction layer comprises a drive initialization interface, a device drive binding interface, a device drive unbinding interface, an opening device interface, a closing device interface, a read-write transmission interface, a write interface, a read interface and a control interface;
the user interface of the consistency API layer comprises an equipment binding driving interface, an equipment unbinding driving interface, an equipment opening interface, an equipment closing interface, a reading and writing equipment interface, a reading equipment interface and an equipment control interface.
In the embodiment of the invention, the calling process of the remote procedure calling layer to the device driver comprises the following sub-steps:
a1: in the client, packaging the identity and the entry parameter of the remote procedure call into interprocess communication data by using an rpc _ call () function, and sending the interprocess communication data to the client through an interprocess communication handle;
it should be noted here that the client is a user process, and when the user process uses the driver unified interface implemented in the third step, the RPC communication is the RPC communication performed by the user on the hardware driver.
A2: receiving interprocess communication data by using a server, calling a callback function corresponding to rpc _ call () function to analyze, and returning the analyzed interprocess communication data to a client through a rpc _ reply () function or a rpc _ reply _ data () function in the callback function;
it should be noted here that when the client calls the driver uniform interface, the server is implemented as the driver abstraction layer interface and the driver bottom layer, and after responding to the call of the client to the driver, the server sends the returned data to the client, where the returned data is the result of the driver call.
A3: and receiving the analyzed interprocess communication data by using the client to complete one-time remote procedure call communication.
And the user uses the RPC to provide client-side service for the user unified interface realized in the third step, and communicates with the service-side service provided by the RPC for the driver abstract layer interface realized in the second step. Therefore, the user completes the call to the hardware driver through RPC communication between the client and the server.
In the embodiment of the invention, in the device manager, the device information is used for describing the hardware device driving system management device; the equipment operation information is used for managing the pre-initialization, the life cycle and the equipment maintenance of the equipment through an equipment manager; the device driver comprises driver loading, driver registration, driver logout and driver unloading;
the driver loading is used for loading a driver ELF file of the equipment; driver registration for associating drivers with devices; the driver logout is used for canceling the association between the driver and the equipment; the driver offload is used to remove the ELF process from the memory;
the device manager (devmgr) in the fifth step is mainly responsible for managing device information, device operation management, and device driver management in the hardware driving method provided by the present invention. The device information refers to management of a system on a device description mode, the device information is written and described by JSON syntax, a current device root node is a system node, the relationship description between devices indicates a parent-child relationship through a pair of key-values in JSON, and a device linked list is created in a device manager (devmgr) according to the device information and the device node linked list. The device operation management means that the device manager manages the pre-initialization, the life cycle and the device maintenance of the device. The device driver management means that the device manager divides the device drivers into four aspects of driver loading, driver registration, driver logout and driver unloading to organize and manage according to the principle of driver existence.
Driver registration is an action that associates a driver with a device. The same driver can not be registered for multiple times at the same time, and when multiple buses and multiple devices exist, a new driver needs to be reloaded, and the device driver needs to be registered again. And driving logout. An action associated with the drive and the device is canceled. After this action, the device will reset to the offline state.
The drive loading comprises static loading and dynamic loading; the static loading is used for calling a drive entry function loading drive to run in the starting process of the hardware equipment drive system; the dynamic loading is used for driving and loading after the hardware device driving system is started, specifically after the devmgr process is started.
Based on the above system, the present invention further provides a hardware device driving method based on microkernel, as shown in fig. 2, including the following steps:
s1: calling and initializing a device driver;
s2: classifying the equipment, and starting an equipment driver and the equipment by utilizing an equipment manager;
s3: performing equipment registration and equipment drive registration based on the started equipment drive and equipment;
s4: calling device drivers in different driver processes;
s5: and in the calling process, judging whether the equipment is disconnected with the equipment driver or not, if so, performing drive logout, and otherwise, continuing equipment driver calling among different drive processes.
The device driver is divided into four aspects of driver loading, driver registration, driver logout and driver uninstallation for organization and management.
In this embodiment of the present invention, in step S1, the specific method for calling the device driver is as follows: acquiring an equipment instance of corresponding equipment from the equipment drive, and performing read-write operation on the equipment instance to finish calling;
an application program applies for obtaining an equipment instance of equipment (such as a usb mouse) from an equipment driver; the device instance and the driver instance have a binding relationship, so that the device instance and the corresponding device driver have a binding relationship. The application program carries out read-write operation on the equipment instance; the essence of the method is that IPC communication is called when API is called to send the device instance id and the relevant information of operation to the device driver, and the result data is returned to the application program through IPC communication after the device driver executes the operation.
Initializing the device driver, wherein the initializing device driver comprises an initializing bus device driver and an initializing specific device driver; the specific method for initializing the bus equipment drive comprises the following steps: starting a bus equipment driver, initiating driver registration to an equipment manager, associating the adapted equipment with the bus equipment driver, and informing the bus equipment driver to initialize by using the equipment manager;
the specific method for initializing the specific device driver comprises the following steps: starting a specific device driver, initiating driver registration to a device manager, associating the adapted device with the specific device driver, and notifying the specific device driver to initialize by using the device manager.
This device initialization procedure is applicable to devices that require dynamic discovery, such as USB and I2C devices. Methods (e.g., device tree files) in which the device manager simultaneously supports statically declared devices skip dynamic discovery to directly notify the appropriate driver module to attempt to initialize the device.
In the embodiment of the present invention, in step S2, the devices are classified into four categories, which are: system key equipment, bus equipment, static equipment and dynamic equipment;
the process of starting the driver and the device needs the device manager to control the process, and the driver framework dynamically creates the api for the device to dynamically register/unregister the device depending on the device management (the device driver provides the device description information, and the device management returns a device ID as a handle). The drives and devices will start in a certain starting sequence, before which the devices and their drives have to be roughly classified into four categories:
system critical device: the system platform device can carry out drive binding after initializing the initial equipment management;
bus-class devices: bus device;
static equipment: static device, the device in the starting file is described by the device tree;
dynamic equipment: dynamic device, a device discovered and created by other devices, can be created and deleted dynamically.
Device initialization (drive binding) in the system is performed in the above order with the aim of ensuring the dependency between the drives. When the dependency relationship exists between the devices, the device (depended party) providing the basic service is preferably initialized to ensure that the depended party device can be normally used.
The specific method for starting the static equipment comprises the following steps: initiating a binding operation by using an equipment manager, judging whether the current drive supports the equipment or not by using an equipment drive, if so, binding an equipment identity identifier and an equipment drive identifier to complete the starting of the static equipment, and if not, continuously traversing a drive list; if the traversed drive list has a drive supporting the equipment, performing binding operation, otherwise waiting for next triggering of the binding operation;
the driver judges whether the driver is the driver supporting the equipment or not, the binding of the driver and the equipment is the traversal driver, whether the driver is matched with the equipment to be bound currently or not is checked, and if the driver is matched with the equipment to be bound currently, the driver and the equipment can be bound; and if the current driver does not support the device, continuing traversing the driver list until the driver matched with the device is found, then binding, and if the traversing list does not exist, waiting for triggering device driver binding next time.
As shown in fig. 3, the device manager may add logic to determine whether the driver and the device match for performance optimization, and in general, the device manager may not be aware of whether the driver and the device match. The device manager may then attempt to initiate a bind operation, and the driver may determine whether the device is supported. The device can bind the device id and the drive id during registration, and the device id can be analyzed to the drive id from the device id acquired in the following operation.
As shown in fig. 4, the specific method for starting the dynamic device is as follows: and calling the equipment monitoring interface by using the equipment manager to monitor whether the new equipment is accessed into the equipment driver, calling the control interface by using the equipment manager to receive the equipment information of the new equipment if the new equipment is accessed into the equipment driver, automatically matching the adaptive equipment driver, and starting the equipment.
As shown in fig. 5, in the embodiment of the present invention, the device registration in step S3 includes static device registration and dynamic device registration, and the registration method of the static device is as follows: analyzing the equipment tree by utilizing the equipment driver to obtain equipment information of the static equipment, initiating a static equipment registration application, returning the static equipment identity identification if the registration is successful, and otherwise, initiating the static equipment registration application again until the static equipment registration is successful;
as shown in fig. 6, in step S3, the method for registering a dynamic device includes the following sub-steps:
a31: analyzing the equipment tree by utilizing equipment driving, and generating and traversing an equipment list;
a32: judging whether the bus successfully matches the device driver with the device, if so, entering the step A33, otherwise, after sleeping within the set time, returning to the step A31;
a33: traversing the drive list, judging whether the equipment drive is loaded successfully or not, if so, applying an equipment drive identity and an equipment identity to the equipment number pool, and entering the step A34, otherwise, sleeping within a set time and returning to the step A31;
a34: creating a daemon process, and monitoring and reporting new dynamic equipment entering an equipment driver in the daemon process;
a35: applying for registering new dynamic equipment;
statically defined devices enter the registration process at system start-up. The statically defined equipment refers to static equipment of a system which is well defined in an equipment tree, firstly the system analyzes the equipment tree to obtain relevant information of the static equipment, then application for registration of the static equipment is initiated, if the registration is successful, an equipment ID is returned, and if the registration is failed, the static equipment is applied again until the registration application of the static equipment is successful.
As shown in fig. 7, in step S3, the device driver registration method for the static device and the mobile device is the same, and each method includes the following sub-steps:
b31: analyzing the equipment tree by utilizing equipment driving, and generating and traversing an equipment list;
b32: judging whether the equipment is successfully matched with the equipment driver or not, if so, entering a step B33, otherwise, sleeping within a set time and returning to the step B31;
b33: traversing the drive list, judging whether the device driver and the device are successfully matched with the drive ELF file, if so, entering a step B34, otherwise, sleeping within a set time and returning to the step B31;
b34: and loading the driver ELF file, setting a matching success identifier, applying for an equipment driver identity from the driver number pool, and finishing equipment driver registration.
As shown in fig. 8, in the embodiment of the present invention, step S4 includes the following sub-steps:
s41: initiating a request for calling a drive process B by using a drive process A;
s42: based on the calling request, calling an equipment management application programming interface to inquire equipment information and equipment driving information and returning the equipment information and the equipment driving information to the A driving process;
s43: and calling the bottom drive layer, the equipment abstraction layer and the consistency API layer of the simulation drive type API drive B drive process, returning to the A drive process, and completing the calling among different drive processes.
Fig. 9 shows a flowchart of the inter-drive call using the inter-drive call interface defined by the command class, where the steps from the first step to the fourth step of the above two inter-drive call flows are not required to be executed every call. The information obtained from the first step to the fourth step is stored in the buffer area, so that if the called driving information is already stored in the buffer area, the first step to the fourth step is skipped without execution, and the information in the buffer area is refreshed according to the mechanism.
The driving use flow mainly relates to three objects of a user, devmgr and a driving process, and the driving use flow is shown in the following fig. 10, and the steps from the first step to the fourth step are not required to be executed every time calling. The information obtained from the first step to the fourth step is stored in the buffer area, so that if the called driving information is already stored in the buffer area, the first step to the fourth step is skipped without execution, and the information in the buffer area is refreshed according to the mechanism.
In the embodiment of the present invention, as shown in fig. 11, the specific process of performing logout in step S5 is: the method comprises the steps of sequentially applying for equipment logout, applying for equipment logout information, releasing equipment resources, unbinding the equipment and an equipment driver, logout of an equipment identity, logout of an equipment driver identity and release of the equipment driver resources.
The working principle and the process of the invention are as follows:
the invention has the beneficial effects that:
(1) the hardware device driving system simplifies the driving abstract layer, so that the hardware driving has lower resource consumption, better maintainability, conciseness, reusability and expandability; the code amount required by the driver transplanting and developing work is reduced, so that the research and development cost of the driver transplanting and developing work is reduced; the decoupling of the driver and the kernel is completed, so that the driver module has stronger flexibility and portability, the stability of the kernel is ensured, and the normal operation of the system is ensured when the driver layer has the problems of accidental collapse and the like.
(2) For developers, the driving framework performs unified processing on all the drivers, and all the driver coding designs are based on the same framework structure and the same abstract layer and user layer interface, so that the complexity of driver coding is greatly reduced, the readability of driver codes is improved, the driver development time of the driver developers is reduced, and the effect of reducing the research and development cost is finally achieved;
(3) for the user, the interface facing the user is simpler, and the complexity of calling between the drivers is reduced;
(4) the hardware device driving method of the present invention can be transplanted and applied to hardware platforms of all architectures, including but not limited to: x86, ARM, Mips, Alpha, PowerPC, and UltraSPARC, among others.
It will be appreciated by those of ordinary skill in the art that the embodiments described herein are intended to assist the reader in understanding the principles of the invention and are to be construed as being without limitation to such specifically recited embodiments and examples. Those skilled in the art can make various other specific changes and combinations based on the teachings of the present invention without departing from the spirit of the invention, and these changes and combinations are within the scope of the invention.
Claims (8)
1. A hardware device driving system based on microkernel is characterized by comprising a bottom driving layer, a device abstraction layer, a consistency API layer, a remote procedure calling layer and a device manager;
the bottom driving layer is used for realizing various operations on the equipment;
the device abstraction layer is used for providing a packaging interface of bottom layer drive operation, and the packaging interface comprises a drive initialization interface, a device drive binding interface, a device drive unbinding interface, an open device interface, a close device interface, a read-write transmission interface, a write interface, a read interface and a control interface;
the consistency API layer is used for carrying out secondary packaging on a packaging interface of the equipment abstraction layer and providing a user interface, and the user interface comprises an equipment binding driving interface, an equipment unbinding driving interface, an equipment opening interface, an equipment closing interface, a reading and writing equipment interface, a reading equipment interface and an equipment control interface;
the remote procedure call layer is used for carrying out remote procedure call communication between a packaging interface of the equipment abstraction layer and a user interface of the consistency API layer, and calling of equipment drivers by a user is realized through the remote procedure call communication between the client and the server;
the device manager is used for managing device information, managing device operation information and managing device drivers.
2. The microkernel-based hardware device driver system of claim 1, wherein in the device manager, the device information is used to describe a hardware device driver system management device; the equipment operation information is used for managing the pre-initialization, the life cycle and the equipment maintenance of the equipment; the device driver comprises driver loading, driver registration, driver logout and driver unloading;
the driver loads a driver ELF file for loading equipment; the driver registration is used to associate a driver and a device; the driver logout is used for canceling the association between the driver and the equipment; the driver offload is used to remove ELF processes from memory;
the drive loading comprises static loading and dynamic loading; the static loading is used for calling a drive entry function loading drive to run in the starting process of the hardware equipment drive system; and the dynamic loading is used for carrying out drive loading after the hardware equipment drive system is started.
3. A microkernel-based hardware device driving method, wherein the microkernel-based hardware device driving method is applied to the microkernel-based hardware device driving system according to any one of claims 1-2, and comprises the following steps:
s1: calling and initializing a device driver;
s2: classifying the equipment, and starting an equipment driver and the equipment by utilizing an equipment manager;
s3: performing equipment registration and equipment drive registration based on the started equipment drive and equipment;
s4: calling device drivers in different driver processes;
s5: and in the calling process, judging whether the equipment is disconnected with the equipment driver or not, if so, performing drive logout, and otherwise, continuing equipment driver calling among different drive processes.
4. The microkernel-based hardware device driving method according to claim 3, wherein in step S1, the specific method for calling the device driver is: acquiring an equipment instance of corresponding equipment from the equipment drive, and performing read-write operation on the equipment instance to finish calling;
initializing the device driver, wherein the initializing device driver comprises an initializing bus device driver and an initializing specific device driver; the specific method for initializing the bus equipment drive comprises the following steps: starting a bus equipment driver, initiating driver registration to an equipment manager, associating the adapted equipment with the bus equipment driver, and informing the bus equipment driver to initialize by using the equipment manager;
the specific method for initializing the specific device driver comprises the following steps: starting a specific device driver, initiating driver registration to a device manager, associating the adapted device with the specific device driver, and notifying the specific device driver to initialize by using the device manager.
5. The microkernel-based hardware device driving method according to claim 3, wherein in step S2, the devices are classified into four categories, respectively: system key equipment, bus equipment, static equipment and dynamic equipment;
the specific method for starting the static equipment comprises the following steps: initiating a binding operation by using an equipment manager, judging whether the current drive supports the equipment or not by using an equipment drive, if so, binding an equipment identity identifier and an equipment drive identifier to complete the starting of the static equipment, and if not, continuously traversing a drive list; if the traversed drive list has a drive supporting the equipment, performing binding operation, otherwise waiting for next triggering of the binding operation;
the specific method for starting the dynamic device comprises the following steps: and calling the equipment monitoring interface by using the equipment manager to monitor whether the new equipment is accessed into the equipment driver, calling the control interface by using the equipment manager to receive the equipment information of the new equipment if the new equipment is accessed into the equipment driver, automatically matching the adaptive equipment driver, and starting the equipment.
6. The microkernel-based hardware device driving method according to claim 3, wherein in step S3, the device registration in step S3 includes static device registration and dynamic device registration, and the static device registration method is as follows: analyzing the equipment tree by utilizing the equipment driver to obtain equipment information of the static equipment, initiating a static equipment registration application, returning the static equipment identity identification if the registration is successful, and otherwise, initiating the static equipment registration application again until the static equipment registration is successful;
in step S3, the method for registering a dynamic device includes the following sub-steps:
a31: analyzing the equipment tree by utilizing equipment driving, and generating and traversing an equipment list;
a32: judging whether the bus successfully matches the device driver with the device, if so, entering the step A33, otherwise, after sleeping within the set time, returning to the step A31;
a33: traversing the drive list, judging whether the equipment drive is loaded successfully or not, if so, applying an equipment drive identity and an equipment identity to the equipment number pool, and entering the step A34, otherwise, sleeping within a set time and returning to the step A31;
a34: creating a daemon process, and monitoring and reporting new dynamic equipment entering an equipment driver in the daemon process;
a35: applying for registering new dynamic equipment;
in step S3, the device driver registration methods of the static device and the dynamic device are the same, and both include the following sub-steps:
b31: analyzing the equipment tree by utilizing equipment driving, and generating and traversing an equipment list;
b32: judging whether the equipment is successfully matched with the equipment driver or not, if so, entering a step B33, otherwise, sleeping within a set time and returning to the step B31;
b33: traversing the drive list, judging whether the device driver and the device are successfully matched with the drive ELF file, if so, entering a step B34, otherwise, sleeping within a set time and returning to the step B31;
b34: and loading the driver ELF file, setting a matching success identifier, applying for an equipment driver identity from the driver number pool, and finishing equipment driver registration.
7. The microkernel-based hardware device driving method according to claim 3, wherein said step S4 includes the following sub-steps:
s41: initiating a request for calling a drive process B by using a drive process A;
s42: based on the calling request, calling an equipment management application programming interface to inquire equipment information and equipment driving information and returning the equipment information and the equipment driving information to the A driving process;
s43: and calling the bottom drive layer, the equipment abstraction layer and the consistency API layer of the simulation drive type API drive B drive process, returning to the A drive process, and completing the calling among different drive processes.
8. The microkernel-based hardware device driving method according to claim 3, wherein the specific process of logging out in step S5 is as follows: the method comprises the steps of sequentially applying for equipment logout, applying for equipment logout information, releasing equipment resources, unbinding the equipment and an equipment driver, logout of an equipment identity, logout of an equipment driver identity and release of the equipment driver resources.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110810358.0A CN113268275B (en) | 2021-07-19 | 2021-07-19 | Hardware equipment driving system based on microkernel and driving method thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110810358.0A CN113268275B (en) | 2021-07-19 | 2021-07-19 | Hardware equipment driving system based on microkernel and driving method thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113268275A CN113268275A (en) | 2021-08-17 |
| CN113268275B true CN113268275B (en) | 2021-09-28 |
Family
ID=77236642
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110810358.0A Active CN113268275B (en) | 2021-07-19 | 2021-07-19 | Hardware equipment driving system based on microkernel and driving method thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113268275B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114697162A (en) * | 2022-03-26 | 2022-07-01 | 浪潮云信息技术股份公司 | Method and system for realizing gateway of Internet of things based on microkernel architecture |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1866202A (en) * | 2005-05-18 | 2006-11-22 | 大唐移动通信设备有限公司 | Drive method for embedded apparatus |
| CN1877522A (en) * | 2006-06-30 | 2006-12-13 | 浙江大学 | Method for accomplishing embedded system based on function component |
| CN102253834A (en) * | 2011-07-05 | 2011-11-23 | 广东星海数字家庭产业技术研究院有限公司 | Linux hardware device driving system based on digital television |
| CN104699518A (en) * | 2015-03-19 | 2015-06-10 | 烟台海颐软件股份有限公司 | Multi-purpose meter reading machine adapter based on microkernel plug-in and realization method thereof |
| CN104714804A (en) * | 2015-03-20 | 2015-06-17 | 东南大学 | Track traffic automatic fare collection system reader-writer middleware |
| CN107015807A (en) * | 2017-04-06 | 2017-08-04 | 青岛海信宽带多媒体技术有限公司 | A kind of device drives management method |
| CN109508202A (en) * | 2018-09-27 | 2019-03-22 | 华东计算技术研究所（中国电子科技集团公司第三十二研究所） | Drive development system, method and medium for embedded operating system |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8321656B2 (en) * | 2009-06-13 | 2012-11-27 | Phoenix Technologies Ltd. | Timer use in extensible firmware interface compliant systems |
| US9866563B2 (en) * | 2016-04-12 | 2018-01-09 | Gaurdknox Cyber Technologies Ltd. | Specially programmed computing systems with associated devices configured to implement secure communication lockdowns and methods of use thereof |
-
2021
- 2021-07-19 CN CN202110810358.0A patent/CN113268275B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1866202A (en) * | 2005-05-18 | 2006-11-22 | 大唐移动通信设备有限公司 | Drive method for embedded apparatus |
| CN1877522A (en) * | 2006-06-30 | 2006-12-13 | 浙江大学 | Method for accomplishing embedded system based on function component |
| CN102253834A (en) * | 2011-07-05 | 2011-11-23 | 广东星海数字家庭产业技术研究院有限公司 | Linux hardware device driving system based on digital television |
| CN104699518A (en) * | 2015-03-19 | 2015-06-10 | 烟台海颐软件股份有限公司 | Multi-purpose meter reading machine adapter based on microkernel plug-in and realization method thereof |
| CN104714804A (en) * | 2015-03-20 | 2015-06-17 | 东南大学 | Track traffic automatic fare collection system reader-writer middleware |
| CN107015807A (en) * | 2017-04-06 | 2017-08-04 | 青岛海信宽带多媒体技术有限公司 | A kind of device drives management method |
| CN109508202A (en) * | 2018-09-27 | 2019-03-22 | 华东计算技术研究所（中国电子科技集团公司第三十二研究所） | Drive development system, method and medium for embedded operating system |
Non-Patent Citations (2)
| Title |
|---|
| 基于微内核的设备驱动框架研究;吴帆;《中国优秀硕士学位论文全文数据库 (信息科技辑)》;20110215;第I138-99页 * |
| 基于灵活内核的构件化驱动程序;杜永文等;《小型微型计算机系统》;20040421;第587-590页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113268275A (en) | 2021-08-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110618876B (en) | Linux and Android coexistence and interaction method based on Feiteng platform and shared kernel | |
| CN107636612B (en) | Application migration device, method and storage medium | |
| US20150220308A1 (en) | Model-based development | |
| CN110187910B (en) | Thermal updating method, device, equipment and computer readable storage medium | |
| CN108141378B (en) | Dormant VDU in VNFD | |
| US20030135785A1 (en) | Configuration proxy service for the extended firmware interface environment | |
| CN113312245B (en) | Integrated waveform management terminal and management method | |
| CN104137062A (en) | Dynamic injection of code into running process | |
| CN114721719B (en) | Method and system for containerized deployment of heterogeneous applications in cluster | |
| CN104699503A (en) | Method and device for replacing function execution logic in Android system | |
| KR101249735B1 (en) | Device and method for executing Android applications on general purpose operating systems, and computer readable recording medium for the same | |
| CN115291946A (en) | Hongmong system transplanting method, device, electronic equipment and readable medium | |
| CN113268275B (en) | Hardware equipment driving system based on microkernel and driving method thereof | |
| CN111443919B (en) | Method for realizing SCA core framework on DSP multi-core processor | |
| CN111752841A (en) | Single test simulation method, device, equipment and computer readable storage medium | |
| CN114968192A (en) | Project creation method and device, computer equipment and storage medium | |
| CN113448643B (en) | Configuration data management system and method | |
| CN113626095A (en) | Switching method and switching system of configuration center, electronic equipment and storage medium | |
| CN102023857A (en) | ServiceOS-based multi-platform application program service management method and system | |
| CN106802805B (en) | Application service management method and device suitable for server management | |
| CN114416202B (en) | Mobile terminal SDK calling method and system | |
| CN111158987A (en) | Health check method and device of micro-service architecture | |
| CN113051088B (en) | Program loading method, device, equipment and computer readable medium | |
| CN113568603B (en) | Component object creating and interface method calling method, terminal and storage device | |
| CN115543546A (en) | Spring-based module heat deployment method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |