CN114237725A - Device driver calling method, device and system - Google Patents
Device driver calling method, device and system Download PDFInfo
- Publication number
- CN114237725A CN114237725A CN202111526253.9A CN202111526253A CN114237725A CN 114237725 A CN114237725 A CN 114237725A CN 202111526253 A CN202111526253 A CN 202111526253A CN 114237725 A CN114237725 A CN 114237725A
- Authority
- CN
- China
- Prior art keywords
- equipment
- driver
- information
- device driver
- mode memory
- 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.)
- Pending
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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The application provides a device driver calling method, device and system. According to the method, the device information acquisition command is sent to the device driver in the kernel mode through the first calling function by the application program in the user mode memory, so that the device driver in the kernel mode memory responds to the device information acquisition command, and the device information is sent to the application program in the user mode memory through the second calling function, so that the device information in the kernel mode memory can be acquired through corresponding function calling in the user mode memory, and therefore the software program running in the embedded operating system can call the device driver through the device information.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, and a system for invoking a device driver.
Background
At present, in some embedded operating systems (such as a VxWorks operating system or an RT-Linux operating system), memories are divided, wherein one part is a kernel-mode memory, and the other part is a user-mode memory.
The kernel mode memory and the user mode memory exist in different memory spaces, the embedded operating system occupies the kernel mode memory space, and the application program occupies the user mode memory space. The operating system can access the kernel mode memory and the user mode memory simultaneously, and the application program can only access the user mode memory space. The driver is run in the kernel mode, and for example, when the driver in the kernel mode is called, the device information needs to be acquired first.
However, in the current embedded operating system, the driver can only execute the corresponding driver function according to the pre-configured device information, and the application program in the user mode memory cannot acquire the device information. Therefore, how to acquire the device information in the kernel-mode memory becomes an urgent problem to be solved.
Disclosure of Invention
The application provides a device driver calling method, device and system, which are used for enabling an application program in a user mode memory to acquire device information in a kernel mode memory.
In a first aspect, the present application provides a device driver invoking method, which is applied to an embedded operating system, where the embedded operating system includes a kernel-mode memory and a user-mode memory, and the method includes:
an application program in the user mode memory sends a device information acquisition command to a device driver in the kernel mode through a first call function;
and the device driver in the kernel mode memory responds to the device information acquisition command and sends device information to the application program in the user mode memory through a second calling function so that a software program running in the embedded operating system calls the device driver through the device information.
In one possible design, before sending device information to the application program in the user mode through the second calling function, the method further includes:
traversing Peripheral Component Interconnect (PCI) equipment in the process of initializing the equipment driver, and reading an equipment identification code of each PCI equipment;
and determining target equipment according to the equipment identification code, and acquiring the equipment information corresponding to the target equipment, wherein the equipment driver is used for driving the target equipment.
In one possible design, the device driver invoking method further includes:
and when detecting that the target equipment is plugged in and pulled out of the PCI slot, starting initialization operation of the equipment driver.
In one possible design, the determining the target device according to the device identification code includes:
determining a corresponding device type according to the device type information in the device identification code of each PCI device;
and determining the PCI equipment of which the equipment type accords with the preset type as the target equipment.
In one possible design, the device driver is a graphics card driver.
In one possible design, the first calling function and the second calling function are functions in the device driver, which manage I/O channels of corresponding devices.
In one possible design, after the sending device information to the application program in the user mode through the second calling function, the method further includes:
the image processing program running in the embedded operating system calls the display card drive through the application program by utilizing the display card information so as to drive the display card currently arranged on the PCI slot to display the image processed by the image processing program, the equipment information comprises the display card information, and the equipment drive comprises the display card drive.
In a second aspect, the present application provides an apparatus for invoking a device driver, including:
the sending module is used for sending a device information acquisition command to a device driver in a kernel mode of the embedded operating system through a first calling function;
and the receiving module is used for sending the equipment information to the application program in the user mode of the embedded operating system through a second calling function so as to enable the software program running in the embedded operating system to call the equipment driver through the equipment information.
In one possible design, the apparatus further includes:
the detection module is used for traversing Peripheral Component Interconnect (PCI) equipment in the process of initializing the equipment driver and reading the equipment identification code of each PCI equipment;
and the determining module is used for determining target equipment according to the equipment identification code and acquiring the equipment information corresponding to the target equipment, and the equipment driver is used for driving the target equipment.
In one possible design, the apparatus further includes:
and the initialization module is used for starting initialization operation of the device driver when the target device is detected to be plugged and unplugged on the PCI slot.
In one possible design, the determining module is specifically configured to:
determining a corresponding device type according to the device type information in the device identification code of each PCI device;
and determining the PCI equipment of which the equipment type accords with the preset type as the target equipment.
In one possible design, the device driver is a graphics card driver.
In one possible design, the first calling function and the second calling function are functions in the device driver, which manage I/O channels of corresponding devices.
In one possible design, the apparatus further includes:
the processing module is used for utilizing the display card information through an image processing program running in the embedded operating system and calling the display card drive through the application program so as to drive the display card currently arranged on the PCI slot to display the image processed by the image processing program, the equipment information comprises the display card information, and the equipment drive comprises the display card drive.
In a third aspect, an embodiment of the present application provides an embedded operating system, including a kernel mode memory and a user mode memory;
an application program in the user mode memory sends a device information acquisition command to a device driver in the kernel mode through a first call function;
and the device driver in the kernel mode memory responds to the device information acquisition command and sends device information to the application program in the user mode through a second calling function so that a software program running in the operating system calls the device driver through the device information.
In a fourth aspect, an embodiment of the present application further provides an electronic device, including: at least one processor and memory;
the memory stores computer-executable instructions;
the at least one processor executes computer-executable instructions stored by the memory to cause the electronic device to implement the method of the first aspect as described above.
In a fifth aspect, the present application further provides a non-transitory computer-readable storage medium, in which computer-executable instructions are stored, and when executed by a processor of an electronic device, the computer-executable instructions cause the electronic device to implement the method according to the first aspect.
In a sixth aspect, the present application further provides a computer program, where the computer program is used to implement the method in the first aspect.
According to the device driver calling method, device and system, the device information acquisition command is sent to the device driver in the kernel mode through the first calling function by the application program in the user mode memory, so that the device driver in the kernel mode memory responds to the device information acquisition command, the device information is sent to the application program in the user mode memory through the second calling function, the device information in the kernel mode memory can be acquired by the user mode memory through corresponding function calling, and therefore the software program running in the embedded operating system can call the device driver through the device information.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.
Fig. 1 is an application scenario diagram of a device driver invoking method according to an embodiment of the present application;
fig. 2 is a schematic flowchart of a device driver invoking method according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a device retrieval logic provided in an embodiment of the present application;
fig. 4 is an application scenario diagram of another device driver invoking method according to an embodiment of the present application;
fig. 5 is a schematic flowchart of another device driver invoking method according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a device driver invoking apparatus according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of another device driver invoking apparatus according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. These drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the inventive concepts to those skilled in the art by reference to specific embodiments.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
At present, in some embedded operating systems (for example, VxWorks operating system or RT-Linux operating system) architectures, the memory is usually divided into a kernel-mode memory and a user-mode memory. The kernel mode memory and the user mode memory exist in different memory spaces, the operating system occupies the kernel mode memory space, and the application program occupies the user mode memory space. The operating system can access the kernel mode memory and the user mode memory simultaneously, and the application program can only access the user mode memory space. The driver is run in kernel mode, such as video card driver. However, in the current operating system, the driver can only execute the corresponding driver function according to the device information configured in advance, and the application program in the user mode memory cannot acquire the device information. It should be noted that the application program in the present application is used for connecting the underlying device driver and the upper layer software program, for example, for connecting the image processing program and the graphics card driver.
In order to obtain the device information in the kernel mode memory in the user mode memory, in the embodiment of the application, the device information obtaining command is sent to the device driver in the kernel mode memory through the first calling function by the application program in the user mode memory, so that the device driver in the kernel mode memory responds to the device information obtaining command, and the device information is sent to the application program in the user mode memory through the second calling function, so that the device information in the kernel mode memory can be obtained in the user mode memory through corresponding function calling, and therefore the software program running in the embedded operating system can call the device driver through the device information.
Fig. 1 is an application scenario diagram of a device driver invoking method provided in an embodiment of the present application. Fig. 2 is a flowchart illustrating a device driver invoking method according to an embodiment of the present application. As shown in fig. 1-2, the device driver invoking method provided in this embodiment includes:
In this embodiment, the device driver invoking method may be applied to an embedded operating system, for example: VxWorks operating system or RT-Linux operating system. In the embedded operating system, since it is necessary to limit the access capability between different programs, and prevent them from acquiring the memory data of another program or acquiring the data of a peripheral device and sending the data to the network, two privilege levels are divided: user mode and kernel mode. In kernel mode, all data of the memory, including peripheral devices, can be accessed, for example: display card, hard disk, network card, can also carry out the program switching. In the user mode, only the limited user mode memory can be accessed, and the peripheral equipment is not allowed to be accessed.
In this step, the application program in the user mode memory sends a device information acquisition command to the device driver in the kernel mode through the first call function. The first calling function is a function for managing an I/O channel of corresponding equipment in equipment drive, namely a function of ioctl command type. Optionally, the application program in the user mode memory may send the device file parameter to the device driver in the kernel mode, in addition to sending the device information obtaining command to the device driver in the kernel mode through the first call function, so that the corresponding device driver is found in the kernel mode through the device file parameter, and then the corresponding relationship between the device information obtaining command and the function is determined through the macro definition of the device driver in the kernel mode, thereby determining the corresponding second call function.
And 102, the device driver in the kernel mode memory responds to the device information acquisition command and sends the device information to the application program in the user mode memory through the second calling function.
And after the device driver in the kernel mode receives a device information acquisition command sent by the application program in the user mode memory, responding to the device information acquisition command, and sending device information to the application program in the user mode memory through a second calling function, so that the software program running in the embedded operating system calls the device driver through the device information. The second calling function is also a function for managing an I/O channel of the corresponding device in the device driver, that is, a function of the ioctl command type.
It can be seen that, in steps 101 to 102, by adding a new command (a first call function, a command for acquiring device information) to the ioctl function and adding a new function (a second call function, a function for sending device information) corresponding to the command in the kernel mode, the device information in the kernel mode memory can be acquired in the user mode memory.
In this embodiment, the device information obtaining command is sent to the device driver in the kernel mode through the first call function by the application program in the user mode memory, so that the device driver in the kernel mode memory responds to the device information obtaining command, and the device information is sent to the application program in the user mode memory through the second call function, so that the device information in the kernel mode memory can be obtained through corresponding function call in the user mode memory, and thus the software program running in the embedded operating system can call the device driver through the device information.
In addition, since the device information in the kernel mode memory can be obtained through corresponding function call in the user mode memory, after the device accessed to the system is replaced, the device information of the new device in the kernel mode memory can be obtained through call, so that a software program running in the embedded operating system can call the device driver of the new device through the obtained device information of the new device, and further, various devices can be supported, and the running adaptability and reliability of the system are higher.
Specifically, the initialization operation of the device driver may be started when the target device is detected to be plugged in or unplugged from a Peripheral Component Interconnect (PCI) slot.
Fig. 3 is a schematic diagram of a device retrieval logic according to an embodiment of the present application. As shown in fig. 3, the PCI device may be traversed during initialization of the device driver, and the device id of each PCI device may be read. And then, determining target equipment according to the equipment identification code, and acquiring equipment information corresponding to the target equipment, wherein the target equipment is equipment corresponding to the equipment driver. Specifically, the PCI devices on the PCI bus may be searched through traversal, the device identification code corresponding to each PCI device may be obtained, the corresponding device type may be determined according to the device identification code, and when the determined device type meets the preset type, the corresponding PCI device is the device that needs to call the device driver.
Therefore, the target equipment can be automatically retrieved in a traversing retrieval mode in the process of initializing the equipment driver, and the corresponding equipment information is reserved, so that the equipment driver can distinguish the equipment, and the display card equipment is not identified in a mode of depending on the equipment information configured in advance in the system. Meanwhile, the calling relationship between the first calling function and the second calling function is newly added in the device driver, namely, a new ioctl call is added, so that the device information can be further transmitted to the application program in the user mode.
Fig. 4 is an application scenario diagram of another device driver invoking method according to the embodiment of the present application. Fig. 5 is a flowchart illustrating another device driver invoking method according to an embodiment of the present application. As shown in fig. 4 to 5, the device driver invoking method provided in this embodiment includes:
In this embodiment, the device driver calling method may be applied to a VxWorks operating system, and the application program is a window-class application program, such as Qt.
In this step, the application program in the user mode memory of the VxWorks operating system sends the device information acquisition command to the device driver in the kernel mode through the first call function. The first calling function is a function for managing an I/O channel of corresponding equipment in equipment drive, namely a function of ioctl command type. In this embodiment, in addition to sending the graphics card information acquisition command to the graphics card driver in the kernel mode through the first call function, the application program in the user mode memory may also send the device file parameter to the graphics card driver, so that the corresponding graphics card driver is found in the kernel mode through the device file parameter, and then the corresponding relationship between the graphics card information acquisition command and the function is determined through the macro definition of the graphics card driver in the kernel mode, and then the corresponding second call function is determined.
The method may be that, during the initialization process of the device driver, the peripheral component interconnect standard PCI devices are traversed, and the device identification code of each PCI device is read. The initialization operation of the display card driver may be started when it is detected that the target device is plugged in or unplugged from the PCI slot, or may be started when the system is started for the first time. It should be noted that, in this embodiment, specific conditions for triggering initialization of the graphics card driver are not limited, and the initialization operation of the graphics card driver may be triggered in any scene in which the graphics card driver needs to be updated.
And 203, determining the target display card according to the equipment identification code, and acquiring display card information corresponding to the target display card.
After the device identification code of each PCI device is read, the target graphics card can be determined according to the device identification code, and the graphics card information corresponding to the target graphics card is acquired. The display card in the PCI device may be determined by a Class number in the device identification code for identifying the device type information, and the display card information may include a manufacturer number and a device number of the display card.
In addition, if the independent display card in the PCI equipment cannot be determined through the Class number used for identifying the equipment type information in the equipment identification code, the display card information corresponding to the integrated display card can be acquired, so that normal display can still be performed when the independent display card cannot work normally.
In the process of initializing the video card, the information of the video card is stored in the kernel mode memory, and the information can be obtained by calling the second calling function.
It should be noted that, regardless of the graphics card or other PCI devices, when the PCI device is initialized, the corresponding PCI device information is stored in the kernel-mode memory.
And step 204, the device driver in the kernel mode memory responds to the display card information acquisition command and sends the display card information to the application program in the user mode memory through the second call function.
And after the display card driver in the kernel mode receives a display card information acquisition command sent by an application program in the user mode memory, responding to the display card information acquisition command, and sending display card information to the application program in the user mode memory through a second calling function, so that a software program running in the embedded operating system calls the display card driver through the display card information. The second calling function is also a function for managing an I/O channel of the corresponding graphics card in the graphics card driver, that is, a function of the ioctl command type.
As can be seen, in this embodiment, the application program in the user mode memory sends the graphics card information obtaining command to the graphics card driver in the kernel mode through the first call function, so that the graphics card driver in the kernel mode memory responds to the graphics card information obtaining command and sends the graphics card information to the application program in the user mode memory through the second call function. That is, by adding a new command (a first call function, a command for acquiring the display card information) to the ioctl function and adding a new function (a second call function, a function for sending the display card information) corresponding to the command in the kernel mode, it is realized that the display card information in the kernel mode memory can be acquired in the user mode memory. The display card information in the kernel mode memory can be acquired through corresponding function call in the user mode memory, so that a software program running in the embedded operating system can call the display card driver through the display card information.
In addition, because the current vxWorks display card driver can only execute the corresponding driving function according to the preset display card information, the display card information cannot be obtained by the user mode program, and the application program cannot execute corresponding operations according to different display cards, multiple display cards cannot be supported in the vxWorks system, that is, if the preset display card information is not provided, the system cannot determine the type and the information of the display card, and further cannot call the display card driver.
In this embodiment, in the process of initializing the display card driver, the purpose of automatically retrieving the target display card is achieved in a traversal retrieval manner, and corresponding display card information is retained, so that the display card driver can distinguish the display cards without depending on the display card information pre-configured in the system to identify the display cards of the display cards. Meanwhile, a new ioctl call is added in the display card driver, so that the display card information can be further transmitted to the application program of the user mode.
Further, after the display card information is sent to the application program in the user mode through the second call function, the image processing program running in the vxWorks calls the display card driver through the display card information to drive the display card currently arranged on the PCI slot, so that the image after the image processing program is displayed, and further the image processing program loaded in the vxWorks can call the display card driver according to the obtained display card information and drive the display card to display the image.
Fig. 6 is a schematic structural diagram of a device driver invoking apparatus according to an embodiment of the present application. As shown in fig. 6, the present application provides a device driver invoking apparatus 300, comprising:
a sending module 301, configured to send a device information obtaining command to a device driver in a kernel state of an embedded operating system through a first call function;
a receiving module 302, configured to send device information to an application program in a user mode of the embedded operating system through a second call function, so that a software program running in the embedded operating system calls the device driver through the device information.
Based on the embodiment shown in fig. 6, fig. 7 is a schematic structural diagram of another device driver invoking apparatus provided in the embodiment of the present application. As shown in fig. 7, the device driver invoking apparatus 300 further includes:
the detection module 303 is configured to traverse Peripheral Component Interconnect (PCI) devices in the initialization process of the device driver, and read a device identification code of each PCI device;
a determining module 304, configured to determine a target device according to the device identification code, and acquire the device information corresponding to the target device, where the device driver is used to drive the target device.
In one possible design, the device driver invoking apparatus 300 further includes:
an initialization module 305, configured to start an initialization operation on the device driver when it is detected that the target device is plugged in or unplugged from the PCI slot.
In one possible design, the determining module 304 is specifically configured to:
determining a corresponding device type according to the device type information in the device identification code of each PCI device;
and determining the PCI equipment of which the equipment type accords with the preset type as the target equipment.
In one possible design, the device driver is a graphics card driver.
In one possible design, the first calling function and the second calling function are functions in the device driver, which manage I/O channels of corresponding devices.
In one possible design, the device driver invoking apparatus 300 further includes:
The device driver invoking apparatus provided in this embodiment may be configured to execute the technical solution of any one of the method embodiments, and the implementation principle and the technical effect are similar, which are not described herein again.
In addition, the embodiment of the application also provides an embedded operating system, which comprises a kernel mode memory and a user mode memory; an application program in the user mode memory sends a device information acquisition command to a device driver in the kernel mode through a first call function; and the device driver in the kernel mode memory responds to the device information acquisition command and sends device information to the application program in the user mode through a second calling function so that a software program running in the embedded operating system calls the device driver through the device information.
Fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application. Referring to fig. 8, the electronic device 400 includes a memory 402 and at least one processor 401;
wherein the memory 402 stores computer-executable instructions.
The at least one processor 401 executes computer-executable instructions stored by the memory 402 to cause the electronic device to implement the methods shown in any of the embodiments described above.
In addition, the electronic device may further include a receiver 403 and a transmitter 404, the receiver 403 being configured to receive information from the remaining apparatuses or devices and forward the information to the processor 401, and the transmitter 404 being configured to transmit the information to the remaining apparatuses or devices.
The electronic device provided in this embodiment may be configured to execute the technical solution of the method embodiment shown in any of the above embodiments, and the implementation principle and the technical effect are similar, which are not described herein again.
The embodiment of the present application further provides a non-transitory computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by an electronic element of an electronic device, the computer-executable instructions are used to implement the method shown in any one of the foregoing embodiments.
The embodiment of the present application further provides a computer program, where the computer program is used to implement the method shown in any one of the above embodiments.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
The terms "first," "second," "third," and the like in the description and claims of this application and in the above-described drawings are used for distinguishing between similar or analogous objects or entities and are not necessarily intended to limit the order or sequence of any particular one, Unless otherwise indicated. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein.
Furthermore, the terms "comprises" and "comprising," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a product or device that comprises a list of elements is not necessarily limited to those elements explicitly listed, but may include other elements not expressly listed or inherent to such product or device.
The term "module," as used herein, refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and/or software code that is capable of performing the functionality associated with that element.
It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.
Claims (12)
1. A device driver calling method is applied to an embedded operating system, wherein the embedded operating system comprises a kernel mode memory and a user mode memory, and the method comprises the following steps:
an application program in the user mode memory sends a device information acquisition command to a device driver in the kernel mode through a first call function;
and the device driver in the kernel mode memory responds to the device information acquisition command and sends device information to the application program in the user mode memory through a second calling function so that a software program running in the embedded operating system calls the device driver through the device information.
2. The device driver calling method according to claim 1, further comprising, before the sending device information to the application program in the user mode through the second calling function:
traversing Peripheral Component Interconnect (PCI) equipment in the process of initializing the equipment driver, and reading an equipment identification code of each PCI equipment;
and determining target equipment according to the equipment identification code, and acquiring the equipment information corresponding to the target equipment, wherein the equipment driver is used for driving the target equipment.
3. The device driver invocation method according to claim 2, further comprising:
and when detecting that the target equipment is plugged in and pulled out of the PCI slot, starting initialization operation of the equipment driver.
4. The device driver invoking method according to claim 3, wherein the determining the target device according to the device identification code comprises:
determining a corresponding device type according to the device type information in the device identification code of each PCI device;
and determining the PCI equipment of which the equipment type accords with the preset type as the target equipment.
5. The device driver invoking method according to any one of claims 1 to 4, wherein the device driver is a graphics card driver.
6. The device driver calling method according to claim 5, wherein the first calling function and the second calling function are functions in the device driver that manage I/O channels of corresponding devices.
7. The device driver calling method according to claim 6, further comprising, after the sending device information to the application program in the user mode through the second calling function:
the image processing program running in the embedded operating system utilizes the information of the display card and calls the drive of the display card through the application program so as to drive the display card currently arranged on the PCI slot to display the image processed by the image processing program, the equipment information comprises the information of the display card, and the equipment drive comprises the drive of the display card.
8. An apparatus for invoking a device driver, comprising:
the sending module is used for sending a device information acquisition command to a device driver in a kernel mode of the embedded operating system through a first calling function;
and the receiving module is used for sending the equipment information to the application program in the user mode of the embedded operating system through a second calling function so as to enable the software program running in the embedded operating system to call the equipment driver through the equipment information.
9. An embedded operating system is characterized by comprising a kernel mode memory and a user mode memory;
an application program in the user mode memory sends a device information acquisition command to a device driver in the kernel mode through a first call function;
and the device driver in the kernel mode memory responds to the device information acquisition command and sends device information to the application program in the user mode through a second calling function so that a software program running in the operating system calls the device driver through the device information.
10. An electronic device, comprising: at least one processor and memory;
the memory stores computer-executable instructions;
the at least one processor executing the computer-executable instructions stored by the memory causes the electronic device to implement the method of any of claims 1-7.
11. A computer-readable storage medium having computer-executable instructions stored therein, which, when executed by a processor of an electronic device, cause the electronic device to implement the method of any one of claims 1 to 7.
12. A computer program for implementing the method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111526253.9A CN114237725A (en) | 2021-12-14 | 2021-12-14 | Device driver calling method, device and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111526253.9A CN114237725A (en) | 2021-12-14 | 2021-12-14 | Device driver calling method, device and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114237725A true CN114237725A (en) | 2022-03-25 |
Family
ID=80755732
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111526253.9A Pending CN114237725A (en) | 2021-12-14 | 2021-12-14 | Device driver calling method, device and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114237725A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117047785A (en) * | 2023-10-11 | 2023-11-14 | 大扬智能科技(北京)有限公司 | Robot control method, robot control device, and robot system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050219258A1 (en) * | 2000-02-25 | 2005-10-06 | Microsoft Corporation | System and method for applying color management on captured images |
| CN101826068A (en) * | 2009-03-03 | 2010-09-08 | 英业达股份有限公司 | Method for hot-plugging PCI-E device and application thereof |
| CN103246594A (en) * | 2013-04-08 | 2013-08-14 | 汉柏科技有限公司 | Automatic user state network card detecting method based on Linux kernel |
| CN112015476A (en) * | 2019-05-31 | 2020-12-01 | 龙芯中科技术有限公司 | Display card driving method and device, electronic equipment and storage medium |
-
2021
- 2021-12-14 CN CN202111526253.9A patent/CN114237725A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050219258A1 (en) * | 2000-02-25 | 2005-10-06 | Microsoft Corporation | System and method for applying color management on captured images |
| CN101826068A (en) * | 2009-03-03 | 2010-09-08 | 英业达股份有限公司 | Method for hot-plugging PCI-E device and application thereof |
| CN103246594A (en) * | 2013-04-08 | 2013-08-14 | 汉柏科技有限公司 | Automatic user state network card detecting method based on Linux kernel |
| CN112015476A (en) * | 2019-05-31 | 2020-12-01 | 龙芯中科技术有限公司 | Display card driving method and device, electronic equipment and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 刘树贤等: "PCI总线设备驱动程序的设计与应用", 装备指挥技术学院学报, vol. 14, no. 3 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117047785A (en) * | 2023-10-11 | 2023-11-14 | 大扬智能科技(北京)有限公司 | Robot control method, robot control device, and robot system |
| CN117047785B (en) * | 2023-10-11 | 2023-12-19 | 大扬智能科技(北京)有限公司 | Robot control method, robot control device, and robot system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109213611B (en) | Cross-process communication method, device, terminal and storage medium | |
| CN107704325B (en) | Method and device for transmitting messages between processes | |
| CN114237725A (en) | Device driver calling method, device and system | |
| CN112015476B (en) | Display card driving method and device, electronic equipment and storage medium | |
| CN104685443A (en) | Pinning boot data for faster boot | |
| CN116107922A (en) | Application management method and electronic device | |
| CN109375874B (en) | Method, device and equipment for calling distributed storage | |
| CN111381978B (en) | Method for accessing application program, storage medium and intelligent television | |
| CN116466879A (en) | CXL memory module, memory data replacement method and computer system | |
| CN111198735A (en) | Layer information acquisition method, layer information acquisition device and terminal equipment | |
| CN115729702A (en) | Application program memory configuration method, electronic device and computer storage medium | |
| CN103702193A (en) | Method and device for identifying and recognizing type of intelligent television | |
| CN112100017B (en) | Memory resource monitoring method and device | |
| CN108595123B (en) | Data storage method and device of mobile terminal | |
| CN113157299B (en) | Resource allocation method and system | |
| CN106294170A (en) | The method of testing of embedded control system initialization of variable | |
| CN111026896B (en) | Feature value storage and processing method, device and storage device | |
| CN112631708B (en) | Picture display method and device, electronic equipment and storage medium | |
| CN112711562B (en) | File migration method and device, electronic equipment and storage medium | |
| KR100678609B1 (en) | System and method for calling command function in smartcard, and patch system and method therefor | |
| CN115982060A (en) | Memory recovery method and related device | |
| CN117851321A (en) | Equipment control method, device, electronic equipment and storage medium | |
| CN116599917B (en) | Network port determining method, device, equipment and storage medium | |
| CN114615377B (en) | Application program control method, device and equipment | |
| WO2024025143A1 (en) | Memory management method and apparatus considering performance information |
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 |