CN117193791A - Method for checking compatibility between driving module and kernel, computing device and storage medium - Google Patents

Method for checking compatibility between driving module and kernel, computing device and storage medium Download PDF

Info

Publication number
CN117193791A
CN117193791A CN202311245546.9A CN202311245546A CN117193791A CN 117193791 A CN117193791 A CN 117193791A CN 202311245546 A CN202311245546 A CN 202311245546A CN 117193791 A CN117193791 A CN 117193791A
Authority
CN
China
Prior art keywords
driving module
kernel
version file
compatible
crc value
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
Application number
CN202311245546.9A
Other languages
Chinese (zh)
Inventor
胡晓东
占俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Uniontech Software Technology Co Ltd
Original Assignee
Uniontech Software Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Uniontech Software Technology Co Ltd filed Critical Uniontech Software Technology Co Ltd
Priority to CN202311245546.9A priority Critical patent/CN117193791A/en
Publication of CN117193791A publication Critical patent/CN117193791A/en
Pending legal-status Critical Current

Links

Landscapes

  • Stored Programmes (AREA)

Abstract

The invention discloses a method for checking compatibility of a driving module and a kernel, computing equipment and a storage medium, and relates to the technical field of computers. The method comprises the following steps: and checking whether the dependency symbol of each driving module version file corresponding to the driving module is compatible with the current kernel one by one through a compatibility checking script corresponding to the driving module, comprising: acquiring all the dependent symbol names recorded in the version file of the driving module, searching the corresponding CRC value based on each dependent symbol name, and summarizing to generate a first summarized CRC value; comparing the first summarized CRC value with a second summarized CRC value generated when the driving module version file is compiled under the current kernel, and if the first summarized CRC value and the second summarized CRC value are the same, determining that the dependency symbol of the driving module version file is compatible with the current kernel; and if the dependency symbol of at least one driving module version file corresponding to the driving module is compatible with the current kernel, determining that the driving module is compatible with the current kernel. The invention ensures compatibility while realizing the isolation between the driving module and the kernel.

Description

Method for checking compatibility between driving module and kernel, computing device and storage medium
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method for checking compatibility between a driving module and a kernel, a computing device, and a storage medium.
Background
At present, some hardware equipment manufacturers based on Linux operating systems do not provide drive source codes and only provide binary drive modules. This has the advantage of completely isolating the driver module from the operating system for independent development, but this solution does not guarantee compatibility of vendor provided driver modules with the operating system (kernel) version.
To solve the above-mentioned problems, it is necessary to provide a mechanism for checking whether the driver module is compatible with the kernel version. When any modification occurs on the system that may affect the compatibility of the driver module with the kernel version, for example, when a driver module is installed or the kernel version is upgraded, a compatibility checking mechanism is triggered to determine whether the modification was successful and to do so.
The DKBS technology in the prior art is established on the basis of the active codes of the driving module, and when the kernel version changes, the driving module is triggered to compile exception based on the active codes so as to ensure the compatibility between the new kernel version and the kernel module. By using the DKMS technology, manufacturers are required to strictly adhere to the specification of DKMS to create catalogues when writing drivers, and the Dkms.conf configuration files are written according to requirements, so that compiling engineering is provided, and the automatic construction can be realized after the kernel is updated. However, DKMS technology is not suitable for driving modules without source code.
Therefore, a method for checking compatibility between the driving module and the kernel is needed to solve the problems in the above technical solutions.
Disclosure of Invention
To this end, the present invention provides a method for checking compatibility of a driver module with a kernel, so as to solve or at least alleviate the above problems.
According to one aspect of the present invention, a method for checking compatibility between a driver module and a kernel is provided, the method is executed in a computing device, an operating system of the computing device includes a current kernel, the computing device includes one or more driver software packages corresponding to the driver modules, the driver software packages include a plurality of driver module version files corresponding to the driver modules and a compatibility checking script, the method includes: and checking whether the dependency symbol of each driving module version file corresponding to the driving module is compatible with the current kernel one by one through a compatibility checking script corresponding to the driving module, wherein the method comprises the following steps: acquiring all the dependent symbol names recorded in the version file of the driving module, searching the corresponding CRC value based on each dependent symbol name, and summarizing to generate a first summarized CRC value; comparing the first summarized CRC value with a second summarized CRC value generated when the driving module version file is compiled under the current kernel, and if the first summarized CRC value and the second summarized CRC value are the same, determining that the dependency symbol of the driving module version file is compatible with the current kernel; and if the dependency symbol of at least one driving module version file corresponding to the driving module is compatible with the current kernel, determining that the driving module is compatible with the current kernel.
Optionally, in the method for checking compatibility between a driving module and a kernel according to the present invention, the method further includes: and responding to the operation of updating the current kernel into a new kernel, and checking whether the dependency symbol of each driving module version file corresponding to each driving module is compatible with the new kernel or not through the compatibility checking script corresponding to each driving module.
Optionally, in the method for checking compatibility between a driver module and a kernel according to the present invention, if a dependency symbol of a version file of the driver module is compatible with the current kernel, the method further includes: and establishing soft connection of the version file of the driving module under a default driving path of an operating system.
Optionally, in the method for checking compatibility between a driving module and a kernel according to the present invention, the method further includes: and installing the compatibility checking script corresponding to the driving module under a second preset directory of the operating system.
Optionally, in the method for checking compatibility between a driving module and a core according to the present invention, checking whether a dependency symbol of each driving module version file corresponding to the driving module is compatible with the current core one by one includes: judging whether soft connection of each driving module version file corresponding to the driving module exists or not under a default driving path of an operating system; if not, checking whether the dependency symbol of each drive module version file corresponding to the drive module is compatible with the current kernel one by one.
Optionally, in the method for checking compatibility between a driving module and a kernel according to the present invention, the method further includes: if at least one soft connection of the drive module version file exists, checking whether the dependency symbol of the drive module version file is compatible with the current kernel; and if the driver module version files are not compatible, deleting the soft connection, and then checking whether the dependency symbol of each driver module version file corresponding to the driver module is compatible with the current kernel one by one.
Optionally, in the method for checking compatibility between a driving module and a kernel according to the present invention, the method further includes: when the driving module version file is compiled under the current kernel, recording each dependency symbol name and a corresponding CRC value of the driving module version file in the driving module version file, generating a second summarized CRC value based on all CRC values in a summarizing mode, and storing the second summarized CRC value in the driving module version file.
Optionally, in the method for checking compatibility between a driving module and a kernel according to the present invention, searching for a corresponding CRC value based on each of the dependency symbol names includes: and based on each dependent symbol name, searching a corresponding CRC value from the module.
Optionally, in the method for checking compatibility between a driver module and a kernel according to the present invention, each driver module version file is adapted to be installed under a first predetermined directory of an operating system.
According to one aspect of the invention, there is provided a computing device comprising: at least one processor; a memory storing program instructions, wherein the program instructions are configured to be adapted to be executed by the at least one processor, the program instructions comprising instructions for performing the driver module and kernel compatibility checking method as described above.
According to one aspect of the present invention, there is provided a readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform a driver module and kernel compatibility checking method as described above.
According to the technical scheme of the invention, a method for checking compatibility of a driving module and a kernel is provided, wherein a compatibility checking script corresponding to the driving module is used for checking whether a dependent symbol of each driving module version file corresponding to the driving module is compatible with a current kernel one by one, specifically, all dependent symbol names recorded in the driving module version file are obtained, a corresponding CRC value is searched based on each dependent symbol name and summarized to generate a first summarized CRC value, the first summarized CRC value is compared with a second summarized CRC value generated when the driving module version file is compiled under the current kernel, and if the dependent symbols are the same, the dependent symbols of the driving module version file are determined to be compatible with the current kernel. If the dependency symbol of at least one driver version file corresponding to the driver is compatible with the current kernel, it may be determined that the driver is compatible with the current kernel. According to the technical scheme of the invention, the compatibility checking script corresponding to the driving module can be automatically triggered to check the compatibility of the driving module and the kernel version when a new driving module is added or the kernel version is updated without depending on the source code of the driving module, so that the hardware driving module and the kernel are completely isolated so as to be independently developed, the compatibility of the driving module and the kernel version can be ensured, the adaptation cost of the driving module and the kernel is saved, and the hardware problem checking difficulty is reduced.
The foregoing description is only an overview of the present invention, and is intended to be implemented in accordance with the teachings of the present invention in order that the same may be more clearly understood and to make the same and other objects, features and advantages of the present invention more readily apparent.
Drawings
To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings, which set forth the various ways in which the principles disclosed herein may be practiced, and all aspects and equivalents thereof are intended to fall within the scope of the claimed subject matter. The above, as well as additional objects, features, and advantages of the present disclosure will become more apparent from the following detailed description when read in conjunction with the accompanying drawings. Like reference numerals generally refer to like parts or elements throughout the present disclosure.
FIG. 1 shows a schematic diagram of a computing device 100 according to one embodiment of the invention;
FIG. 2 illustrates a flow diagram of a driver module and kernel compatibility checking method 200 according to one embodiment of the invention.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
FIG. 1 shows a schematic diagram of a computing device 100 according to one embodiment of the invention. As shown in FIG. 1, in a basic configuration, computing device 100 includes at least one processing unit 102 and a system memory 104. According to one aspect, the processing unit 102 may be implemented as a processor, depending on the configuration and type of computing device. The system memory 104 includes, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read only memory), flash memory, or any combination of such memories. According to one aspect, an operating system 105 is included in system memory 104.
According to one aspect, operating system 105 is suitable, for example, for controlling the operation of computing device 100. Further, examples are practiced in connection with a graphics library, other operating systems, or any other application program and are not limited to any particular application or system. This basic configuration is illustrated in fig. 1 by those components within the dashed line. According to one aspect, computing device 100 has additional features or functionality. For example, according to one aspect, computing device 100 includes additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in fig. 1 by removable storage device 109 and non-removable storage device 110.
As set forth hereinabove, according to one aspect, the program module 103 is stored in the system memory 104. According to one aspect, program modules 103 may include one or more applications, the invention is not limited in the type of application, for example, the application may include: email and contacts applications, word processing applications, spreadsheet applications, database applications, slide show applications, drawing or computer-aided application, web browser applications, etc.
According to one aspect, program module 103 includes a plurality of program instructions adapted to perform the driver module and kernel compatibility checking method 200 of the present invention.
According to one aspect, the examples may be practiced in a circuit comprising discrete electronic components, a packaged or integrated electronic chip containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic components or a microprocessor. For example, examples may be practiced via a system on a chip (SOC) in which each or many of the components shown in fig. 1 may be integrated on a single integrated circuit. According to one aspect, such SOC devices may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all of which are integrated (or "burned") onto a chip substrate as a single integrated circuit. When operating via an SOC, the functionality described herein may be operated via dedicated logic integrated with other components of computing device 100 on a single integrated circuit (chip). Embodiments of the invention may also be practiced using other techniques capable of performing logical operations (e.g., AND, OR, AND NOT), including but NOT limited to mechanical, optical, fluidic, AND quantum techniques. In addition, embodiments of the invention may be practiced within a general purpose computer or in any other circuit or system.
According to one aspect, the computing device 100 may also have one or more input devices 112, such as a keyboard, mouse, pen, voice input device, touch input device, and the like. Output device(s) 114 such as a display, speakers, printer, etc. may also be included. The foregoing devices are examples and other devices may also be used. Computing device 100 may include one or more communication connections 116 that allow communication with other computing devices 118. Examples of suitable communication connections 116 include, but are not limited to: RF transmitter, receiver and/or transceiver circuitry; universal Serial Bus (USB), parallel and/or serial ports.
The term computer readable media as used herein includes computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information (e.g., computer readable instructions, data structures, or program modules 103). System memory 104, removable storage 109, and non-removable storage 110 are all examples of computer storage media (i.e., memory storage). Computer storage media may include Random Access Memory (RAM), read Only Memory (ROM), electrically erasable read only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article of manufacture that can be used to store information and that can be accessed by computing device 100. According to one aspect, any such computer storage media may be part of computing device 100. Computer storage media does not include a carrier wave or other propagated data signal.
According to one aspect, communication media is embodied by computer readable instructions, data structures, program modules 103, or other data in a modulated data signal (e.g., carrier wave or other transport mechanism) and includes any information delivery media. According to one aspect, the term "modulated data signal" describes a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio Frequency (RF), infrared, and other wireless media.
In an embodiment according to the invention, the computing device 100 is configured to perform a driver module and kernel compatibility checking method 200 according to the invention. The computing device 100 includes one or more processors and one or more readable storage media storing program instructions that, when configured to be executed by the one or more processors, cause the computing device 100 to perform the driver module and kernel compatibility checking method 200 in embodiments of the present invention to check the compatibility of the driver module with kernel versions.
FIG. 2 illustrates a flow diagram of a driver module and kernel compatibility checking method 200 according to one embodiment of the invention. The method 200 is suitable for execution in a computing device (the aforementioned computing device 100).
In an embodiment according to the present invention, the current kernel is included in the operating system of the computing device 100, and the computing device 100 includes one or more driver packages respectively corresponding to one or more driver modules, where each driver module corresponds to one driver package respectively. The driving software package corresponding to the driving module may include a plurality of driving module version files (i.e., a plurality of driving module files with different versions) corresponding to the driving module and a compatibility checking script. The drive module version file is, for example, a ko file.
In some embodiments, before performing the method 200 of the present invention, a software package packaging method may be utilized to package a plurality of driver module version files and compatibility checking scripts corresponding to each driver module to generate a driver software package corresponding to each driver module. In some implementations, the software package packing method may be implemented as, for example, yum, deb, etc. packing techniques, but the invention is not limited thereto.
For example, in one embodiment, the drive module name may be hello, and the plurality of drive module version files (ko files) in the drive software package corresponding to the drive module may include hello-v1.Ko, hello-v2.Ko, hello-v3.Ko, and so on. The compatibility checking script corresponding to the driving module is, for example, hello-sysbols-check.
In one embodiment, each drive module version file (ko file) may be installed under a first predetermined directory of the operating system, which may be, for example, per usr/lib/uos-ko/hello/.
As shown in fig. 2, the method 200 begins at step 210.
In step 210, it is checked, one by one, through the compatibility checking script corresponding to the driving module, whether the dependency symbol of each driving module version file (under the first predetermined directory) corresponding to the driving module is compatible with the current kernel (current kernel version).
It should be noted that, when a driving software package corresponding to a driving module (including a plurality of driving module version files corresponding to the driving module and a compatibility checking script) is newly installed in the computing device 100, the compatibility checking script corresponding to the driving module may be triggered, and the compatibility checking of the driving module and the current kernel is performed, that is, the executing step 210 is triggered.
In some embodiments, in step 210, it is checked whether the dependency symbol of each driver module version file corresponding to the driver module is compatible with the current kernel, which may specifically include the following steps 211 and 212.
In step 211, all the dependency symbol names recorded in the driver module version file (ko file) are acquired, the corresponding CRC values are searched for based on each dependency symbol name, and all the CRC values found based on all the dependency symbol names are summarized to generate a first summarized CRC value.
Subsequently, in step 212, the generated first summarized CRC value is compared with a second summarized CRC value generated when the driver module version file (ko file) is compiled under the current kernel (i.e., when the driver module version file is compiled under the current kernel using a compiler), and if the first summarized CRC value is identical to the second summarized CRC value, it may be determined that the dependency sign of the driver module version file is compatible with the current kernel (current kernel version).
Here, in one embodiment, when the kernel image (e.g., the current kernel image) is compiled, a corresponding CRC value may be calculated for each derived symbol (including a dependency symbol of each driver module version file), and information such as the CRC value and a corresponding symbol name (dependency symbol name) may be saved in the module. Therefore, in this embodiment, after all the dependency symbol names recorded in the drive module version file (ko file) are acquired, the CRC value corresponding to the dependency symbol name may be found from the module.
In one embodiment, a second summarized CRC value generated when the driver module version file is compiled under the current kernel may be saved in the driver module version file. Based on this, a second summarized CRC value may be obtained from the driver module version file and the generated first summarized CRC value may be compared with the second summarized CRC value.
In a specific embodiment, in the method 200 of the present invention, when the driver module version file is compiled under the current kernel, each dependency symbol name and corresponding CRC value of the driver module version file may be recorded in the driver module version file, and a second summarized CRC value may be generated based on all CRC values corresponding to all dependency symbol names in a summarized manner, and then, the second summarized CRC value generated herein may be stored in the driver module version file. For example, in one implementation, the compile-time generated second aggregate CRC value may be saved in a kabi-CRC field in a modinfo file of a driver module version file (ko file).
In one implementation, each dependency symbol name and corresponding CRC value may be checked using a Modprobe-dump-modifications xxx.ko command when the driver module version file is compiled under the current kernel.
In step 220, if the dependency notation of at least one driver module version file corresponding to the driver module is compatible with the current kernel, it may be determined that the driver module is compatible with the current kernel (current kernel version).
In some embodiments, if the dependency notation of the driver module version file is compatible with the current kernel, a software connection for the driver module version file may be established under the default drive path of the operating system. For example, in one implementation, the establishment of a software link to a driver module version file under the default drive path of the operating system may be accomplished by: ln-s/usr/lib/modules/'uname-r' -updates/hello.ko- >/usr/lib/uos-ko/hello/hello-xx.ko.
In some embodiments, before checking whether the dependency symbol of each driving module version file corresponding to the driving module is compatible with the current kernel one by one through the compatibility checking script corresponding to the driving module, whether soft connection of each driving module version file corresponding to the driving module exists in a default driving path of the operating system may be determined by the compatibility checking script corresponding to the driving module, and if soft connection of each driving module version file does not exist, whether the dependency symbol of each driving module version file corresponding to the driving module is compatible with the current kernel one by one may be checked.
If there is at least one soft connection of the driver module version file under the default driving path of the operating system, checking whether the dependency symbol of the driver module version file is compatible with the current kernel. If not, deleting the soft connection, and checking whether the dependency symbol of each driving module version file corresponding to the driving module is compatible with the current kernel one by one. If the dependency notation of the driver module version file is compatible with the current kernel, no subsequent steps need to be performed.
In addition, in some embodiments, if the dependency notation of the driver module version file is compatible with the current kernel, a compatibility check script corresponding to the driver module may also be installed to the operating system. Specifically, a compatibility check script (e.g., hello-sysbols-check. Sh script) corresponding to the driver module may be installed under a second predetermined directory of the operating system. The second predetermined directory may be implemented as a/usr/lib/uos-ko/sysbols-check/directory, for example.
According to the method 200 of the present invention, when the current kernel (the current kernel version) is updated to a new kernel (the new kernel version), the computing device 100 may further check whether the dependency symbol of each driver module version file corresponding to the driver module is compatible with the new kernel one by one through the compatibility checking script corresponding to each driver module, respectively, in response to the operation of updating the current kernel to the new kernel.
It should be understood that in the case of updating the current kernel to a new kernel, it is necessary to check the compatibility of the driving module with the new kernel for each driving module (each driving module that has passed the compatibility check with the current kernel), and thus, for each driving module, it is necessary to check whether the dependency symbol of each driving module version file corresponding to the driving module is compatible with the new kernel one by one through the compatibility check script corresponding to the driving module.
In some embodiments, if the dependency symbol of the driver module version file is compatible with the current kernel, the compatibility checking script corresponding to the driver module may be installed under a second predetermined directory of the operating system. Based on this, when the current kernel is updated to a new kernel, the computing device 100 may call a compatibility check script corresponding to each driving module under the second predetermined directory in response to an operation of updating the current kernel to the new kernel so as to check whether the dependency symbol of each driving module version file corresponding to the driving module is compatible with the new kernel (new kernel version) one by one through the compatibility check script corresponding to the driving module.
Here, it can be understood that, the specific method for checking whether the dependency symbol of each driver module version file corresponding to the driver module is compatible with the new kernel is the same as the implementation method of the foregoing step 210, and specifically may include the following steps: and acquiring all the dependency symbol names recorded in the version file of the driving module, searching corresponding CRC values based on each dependency symbol name, and summarizing all the found CRC values based on all the dependency symbol names to generate a first summarized CRC value. Subsequently, the first summarized CRC value generated herein is compared to a second summarized CRC value generated when the driver module version file is compiled under the new kernel (i.e., when the driver module version file is compiled under the new kernel using a compiler), and if the first summarized CRC value is the same as the second summarized CRC value, it may be determined that the dependency sign of the driver module version file is compatible with the new kernel (new kernel version).
According to the method 200 for checking the compatibility of the driving module and the kernel, the dependency symbol of each driving module version file corresponding to the driving module is checked one by one to check whether the driving module version file is compatible with the current kernel or not through the compatibility checking script corresponding to the driving module, specifically, all dependency symbol names recorded in the driving module version file are obtained, the corresponding CRC value is searched and summarized based on each dependency symbol name to generate a first summarized CRC value, the first summarized CRC value is compared with a second summarized CRC value generated when the driving module version file is compiled under the current kernel, and if the dependency symbol of the driving module version file is identical to the current kernel, the dependency symbol of the driving module version file is determined to be compatible with the current kernel. If the dependency symbol of at least one driver version file corresponding to the driver is compatible with the current kernel, it may be determined that the driver is compatible with the current kernel. According to the technical scheme of the invention, the compatibility checking script corresponding to the driving module can be automatically triggered to check the compatibility of the driving module and the kernel version when a new driving module is added or the kernel version is updated without depending on the source code of the driving module, so that the hardware driving module and the kernel are completely isolated so as to be independently developed, the compatibility of the driving module and the kernel version can be ensured, the adaptation cost of the driving module and the kernel is saved, and the hardware problem checking difficulty is reduced.
The various techniques described herein may be implemented in connection with hardware or software or, alternatively, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions of the methods and apparatus of the present invention, may take the form of program code (i.e., instructions) embodied in tangible media, such as removable hard drives, U-drives, floppy diskettes, CD-ROMs, or any other machine-readable storage medium, wherein, when the program is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.
In the case of program code execution on programmable computers, the mobile terminal will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Wherein the memory is configured to store program code; the processor is configured to execute the driver module and kernel compatibility checking method of the present invention in accordance with instructions in said program code stored in the memory.
By way of example, and not limitation, readable media comprise readable storage media and communication media. The readable storage medium stores information such as computer readable instructions, data structures, program modules, or other data. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above are also included within the scope of readable media.
In the description provided herein, algorithms and displays are not inherently related to any particular computer, virtual system, or other apparatus. Various general-purpose systems may also be used with examples of the invention. The required structure for a construction of such a system is apparent from the description above. In addition, the present invention is not directed to any particular programming language. It will be appreciated that the teachings of the present invention described herein may be implemented in a variety of programming languages, and the above description of specific languages is provided for disclosure of enablement and best mode of the present invention.
In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects.
Those skilled in the art will appreciate that the modules or units or components of the devices in the examples disclosed herein may be arranged in a device as described in this embodiment, or alternatively may be located in one or more devices different from the devices in this example. The modules in the foregoing examples may be combined into one module or may be further divided into a plurality of sub-modules.
Those skilled in the art will appreciate that the modules in the apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. The modules or units or components of the embodiments may be combined into one module or unit or component and, furthermore, they may be divided into a plurality of sub-modules or sub-units or sub-components.
Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features but not others included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments.
Furthermore, some of the embodiments are described herein as methods or combinations of method elements that may be implemented by a processor of a computer system or by other means of performing the functions. Thus, a processor with the necessary instructions for implementing the described method or method element forms a means for implementing the method or method element. Furthermore, the elements of the apparatus embodiments described herein are examples of the following apparatus: the apparatus is for carrying out the functions performed by the elements for carrying out the objects of the invention.
As used herein, unless otherwise specified the use of the ordinal terms "first," "second," "third," etc., to describe a general object merely denote different instances of like objects, and are not intended to imply that the objects so described must have a given order, either temporally, spatially, in ranking, or in any other manner.
While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of the above description, will appreciate that other embodiments are contemplated within the scope of the invention as described herein. Furthermore, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter.

Claims (11)

1. A method for checking compatibility between a driving module and a kernel, which is executed in a computing device, wherein an operating system of the computing device includes a current kernel, the computing device includes one or more driving software packages respectively corresponding to the driving modules, and the driving software packages include a plurality of driving module version files and compatibility checking scripts corresponding to the driving modules, and the method includes:
and checking whether the dependency symbol of each driving module version file corresponding to the driving module is compatible with the current kernel one by one through a compatibility checking script corresponding to the driving module, wherein the method comprises the following steps:
acquiring all the dependent symbol names recorded in the version file of the driving module, searching the corresponding CRC value based on each dependent symbol name, and summarizing to generate a first summarized CRC value;
comparing the first summarized CRC value with a second summarized CRC value generated when the driving module version file is compiled under the current kernel, and if the first summarized CRC value and the second summarized CRC value are the same, determining that the dependency symbol of the driving module version file is compatible with the current kernel;
and if the dependency symbol of at least one driving module version file corresponding to the driving module is compatible with the current kernel, determining that the driving module is compatible with the current kernel.
2. The method of claim 1, further comprising:
and responding to the operation of updating the current kernel into a new kernel, and checking whether the dependency symbol of each driving module version file corresponding to each driving module is compatible with the new kernel or not through the compatibility checking script corresponding to each driving module.
3. The method of claim 1, wherein if the dependency notation of the driver module version file is compatible with the current kernel, further comprising:
and establishing soft connection of the version file of the driving module under a default driving path of an operating system.
4. A method as claimed in claim 3, further comprising:
and installing the compatibility checking script corresponding to the driving module under a second preset directory of the operating system.
5. The method of any of claims 1-4, wherein checking, one by one, whether the dependency notation of each drive module version file corresponding to the drive module is compatible with the current kernel comprises:
judging whether soft connection of each driving module version file corresponding to the driving module exists or not under a default driving path of an operating system;
if not, checking whether the dependency symbol of each drive module version file corresponding to the drive module is compatible with the current kernel one by one.
6. The method of claim 5, further comprising:
if at least one soft connection of the drive module version file exists, checking whether the dependency symbol of the drive module version file is compatible with the current kernel;
and if the driver module version files are not compatible, deleting the soft connection, and then checking whether the dependency symbol of each driver module version file corresponding to the driver module is compatible with the current kernel one by one.
7. The method of any one of claims 1-4, further comprising:
when the driving module version file is compiled under the current kernel, recording each dependency symbol name and a corresponding CRC value of the driving module version file in the driving module version file, generating a second summarized CRC value based on all CRC values in a summarizing mode, and storing the second summarized CRC value in the driving module version file.
8. The method of any of claims 1-4, wherein finding a corresponding CRC value based on each of the dependency names, respectively, comprises:
and based on each dependent symbol name, searching a corresponding CRC value from the module.
9. The method of any of claims 1-4, wherein each of the drive module version files is adapted to be installed under a first predetermined directory of an operating system.
10. A computing device, comprising:
at least one processor; and
a memory storing program instructions, wherein the program instructions are configured to be adapted to be executed by the at least one processor, the program instructions comprising instructions for performing the method of any of claims 1-9.
11. A readable storage medium storing program instructions which, when read and executed by a computing device, cause the computing device to perform the method of any of claims 1-9.
CN202311245546.9A 2023-09-25 2023-09-25 Method for checking compatibility between driving module and kernel, computing device and storage medium Pending CN117193791A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311245546.9A CN117193791A (en) 2023-09-25 2023-09-25 Method for checking compatibility between driving module and kernel, computing device and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311245546.9A CN117193791A (en) 2023-09-25 2023-09-25 Method for checking compatibility between driving module and kernel, computing device and storage medium

Publications (1)

Publication Number Publication Date
CN117193791A true CN117193791A (en) 2023-12-08

Family

ID=88992294

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311245546.9A Pending CN117193791A (en) 2023-09-25 2023-09-25 Method for checking compatibility between driving module and kernel, computing device and storage medium

Country Status (1)

Country Link
CN (1) CN117193791A (en)

Similar Documents

Publication Publication Date Title
US20060064576A1 (en) Boot systems and methods
US8745601B1 (en) Methods and systems for using data structures for operating systems
US5671417A (en) Method and system for inserting floating code hooks into multiple versions of code
CN113835620A (en) Method and system for improving application execution efficiency of security chip
US20040181777A1 (en) Method and device for programming electronic devices using a uniform parameter format
CN114490103A (en) Operating system interface calling method and device and electronic equipment
CN117193791A (en) Method for checking compatibility between driving module and kernel, computing device and storage medium
CN114780173B (en) Method for loading plug-in application, computing device and storage medium
CN116225618A (en) Method for starting virtual machine based on container mirror image and virtual machine starting device
CN113641389B (en) Software upgrading method, device and equipment based on OpenCPU
CN115374017A (en) Method for capturing site during simulation running of executable file and computing equipment
CN115629795A (en) Configuration method and device of executable file and electronic equipment
CN112052112A (en) Bit flipping error detection method and device based on NOR Flash storage and storage medium
CN112286572A (en) Configuration method and device of business process
CN112416444A (en) Board switching control method, device, equipment and medium
WO2019157891A1 (en) Application installation method and application installer generating method
CN105630558A (en) Upgrading method and electronic equipment
CN116991427B (en) Application compiling method and device, computing equipment and storage medium
CN115658075A (en) Software package compiling method and device, computing equipment and storage medium
CN115185634A (en) Subsystem implementation method and computing device
CN115291852B (en) Development method, device, equipment and medium of Sketch plug-in
CN112231176B (en) Simple and convenient log recording method for VxWorks operating system
CN113778535B (en) Cloud host operation verification method, system, equipment and storage medium
US20230280994A1 (en) Information processing device and installation support method
CN118055064A (en) Route information synchronization method, device, computing equipment and storage medium

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