CN120596118A

CN120596118A - Kernel program updating method, device, equipment and storage medium

Info

Publication number: CN120596118A
Application number: CN202510637585.6A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Mole Thread Intelligent Technology Beijing Co ltd
Current assignee: Mole Thread Intelligent Technology Beijing Co ltd
Priority date: 2025-05-16
Filing date: 2025-05-16
Publication date: 2025-09-05

Abstract

A method, a device, equipment and a storage medium for updating kernel programs relate to the technical field of computers. The method comprises the steps of receiving a program updating instruction, wherein the program updating instruction is used for updating a kernel program in an operating system, the kernel program comprises a first kernel module and a second kernel module, the first kernel module is used for receiving a service request aiming at hardware equipment and sending a call request to the second kernel module according to the service request, the second kernel module is used for interacting with the hardware equipment to process the service request under the condition of receiving the call request, unloading the second kernel module from a memory of the operating system, and loading an updated version of the second kernel module into the memory of the operating system. The application splits the kernel program into the first kernel module and the second kernel module, and supports the interaction of the first kernel module with the hardware equipment through the second kernel module, so that the second kernel module is decoupled from the service, thereby realizing the hot update of the kernel program by updating the second kernel module.

Description

Kernel program updating method, device, equipment and storage medium

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a method, a device, equipment and a storage medium for updating a kernel program.

Background

An Operating System (OS) is a System software that can be used to manage and control hardware devices and software resources of a computer device. The operating system includes a kernel program, which refers to code running in the kernel space of the operating system, which can interact directly with the hardware device. For kernel programs included in an operating system, the kernel programs are updated as much as possible without interrupting the original service.

The method for updating the kernel program in the related technology comprises the steps of clearing the reference count of the kernel program, namely removing the reference of all other application programs to the kernel program before unloading the kernel program so as to avoid unloading failure, then unloading the kernel program from the memory of the operating system, and then loading the kernel program with a new version so as to finish updating the kernel program.

However, the above-described clearing of the reference count requires shutting down all traffic related to the kernel program, so that the related art cannot update the kernel program without interrupting the traffic.

Disclosure of Invention

The embodiment of the application provides a method, a device, equipment and a storage medium for updating a kernel program. The technical scheme provided by the embodiment of the application comprises the following contents.

According to an aspect of the embodiment of the present application, there is provided a method for updating a kernel program, the method including:

Receiving a program update instruction, wherein the program update instruction is used for updating a kernel program in an operating system, the kernel program comprises a first kernel module and a second kernel module, the first kernel module is used for receiving a service request aiming at a hardware device, and sending a call request to the second kernel module according to the service request, and the second kernel module is used for interacting with the hardware device to process the service request under the condition of receiving the call request;

unloading the second kernel module from the memory of the operating system;

and loading the updated version of the second kernel module into the memory of the operating system.

According to an aspect of an embodiment of the present application, there is provided a computer apparatus including an operating system including a program management module and a kernel program;

The kernel program comprises a first kernel module and a second kernel module, wherein the first kernel module is used for receiving a service request aiming at hardware equipment and sending a call request to the second kernel module according to the service request, and the second kernel module is used for interacting with the hardware equipment to process the service request under the condition of receiving the call request;

The program management module is used for:

Receiving a program update instruction, wherein the program update instruction is used for updating the kernel program;

unloading the second kernel module from the memory of the operating system;

According to an aspect of an embodiment of the present application, there is provided a computer apparatus including a processor and a memory, in which a computer program is stored, the computer program being loaded and executed by the processor to implement the above-described kernel program updating method.

According to an aspect of the embodiment of the present application, there is provided a computer-readable storage medium having stored therein a computer program loaded and executed by a processor to implement the above-described kernel program updating method.

According to an aspect of an embodiment of the present application, there is provided a computer program product comprising a computer program stored in a computer readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program so that the computer device executes the above-described update method of the kernel program.

The technical scheme provided by the embodiment of the application can have the following beneficial effects.

The first kernel module is coupled with the service, and the second kernel module is decoupled from the service by splitting the kernel program into the first kernel module for receiving the service request and the second kernel module for interacting with the hardware device and supporting the first kernel module to interact with the hardware device through the second kernel module to process the service request. Therefore, the receiving of the service request and the state maintenance of the service can be realized by controlling the memory of the resident operating system of the first kernel module, and the updating of the kernel program is completed by updating the second kernel module, so that the user is free from feeling, and the kernel program is updated under the condition of not interrupting the service.

In addition, the embodiment of the application supports the update by taking the kernel module as a unit, and is not limited to the update by taking the function as a unit, which is beneficial to supporting the large-scale function update of the kernel program, such as the large-scale update of a structure body, a function and the like, thereby being beneficial to improving the upgrading convenience of the kernel program.

In addition, the update of the kernel program can be completed by executing the common installation and uninstallation flow aiming at the second kernel module without introducing a third-party tool or depending on the kernel configuration of the operating system, which is beneficial to improving the universality of the technical scheme provided by the embodiment of the application.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a computer device provided in one possible implementation of the application;

FIG. 2 is a schematic diagram of a split kernel program provided in one possible implementation of the present application;

FIG. 3 is a schematic diagram of a split kernel program provided in another possible implementation of the present application;

FIG. 4 is a flow chart of a method of updating a kernel provided in one possible implementation of the present application;

FIG. 5 is a schematic diagram of the update process of a kernel provided in one possible implementation of the present application;

FIG. 6 is a schematic diagram of an update process of a kernel provided in another possible implementation of the present application;

FIG. 7 is a block diagram of an update apparatus for a kernel provided in one possible implementation of the present application;

FIG. 8 is a block diagram of an update apparatus for a kernel provided in another possible implementation of the present application;

Fig. 9 is a simplified block diagram of a computer device provided in one possible implementation of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail with reference to the accompanying drawings.

Before describing the embodiments of the present application, in order to facilitate understanding of the technical solutions provided by the embodiments of the present application, an operating system, a kernel, and a kernel program related to the embodiments of the present application are described first.

An Operating System (OS) is a System software that can be used to manage and control hardware devices and software resources of a computer device. The operating system may be implemented as the most basic system software that runs directly on the bare computer (Bare Machine) of the computer device, with the other software running under the support of the operating system. The operating system interfaces up to software resources (e.g., user-mode programs) and takes over hardware devices down.

A Kernel (Kernel) is a core part of an operating system that can interact directly with the hardware devices of a computer device to manage the hardware devices of the computer device. For example, the kernel may be responsible for interacting with a hard disk, memory, and other hardware devices connected to an operating system. When the operating system is started, the kernel is required to be loaded into the memory, and the kernel is always kept in the memory until the operating system is closed.

Kernel programs refer to programs that run in the kernel space of an operating system, such as may be loaded into the kernel of an operating system, directly interacting with the kernel to perform specific system tasks. Kernel programs may be written by developers of the operating system for monitoring, managing, and optimizing the performance of the operating system. Wherein kernel space (KERNEL SPACE) is the memory space in which the kernel runs. Kernel space is the area of computer memory that is specifically allocated to the kernel, which can only run in kernel space. Programs in User Space (User Space) cannot directly access data or codes in kernel Space, and need to enter the kernel Space through system call, and the kernel is used for execution instead, so that the safety and stability of an operating system are ensured. The user space is the memory space in which the user mode program operates.

Alternatively, the function of the kernel program may be a function split of the kernel, or may be a function extension of the kernel. The kernel program may be implemented as different programs corresponding to different functions. Illustratively, the functions of the kernel program may be implemented as at least one of device drivers, system monitoring tools, security management, network communications, power management, clock management, etc., which are not limited in this regard by embodiments of the present application. Where the functionality of the kernel is implemented as a device driver, it may be referred to as a kernel driver or device driver. The kernel may manage different hardware devices through the kernel driver.

Optionally, the kernel program exists in the form of a module that can be dynamically loaded into or unloaded from the kernel, which enables the operating system to flexibly support various hardware devices without recompilation of the entire kernel each time a hardware device is added or replaced.

In the embodiment of the application, the kernel program can convert the service request for the hardware equipment into the instruction which can be understood by the hardware equipment so as to realize the interaction with the hardware equipment. The service request for the hardware device may be a request to the hardware device to implement a specified function. For example, a process of a user mode program may interact with a kernel program through a system call, e.g., it may initiate a system call request to a kernel through an interface of the system call, and the kernel program may then convert the system call request into an instruction that may be understood by a hardware device to interact with the hardware device.

The user state program is an application program in a user state when being executed. When executing system call and being trapped in kernel program for execution, the process of application program is in kernel state, and when executing own code, the process of application program is in user state.

The memory of the operating system refers to the memory resources used by the operating system when running, which is part of the computer memory. The operating system maps memory onto virtual memory, providing independent memory space for each program. The memory space allocated by an operating system to a program is commonly referred to as virtual memory, which includes kernel space and user space.

Currently, for kernel programs on an operating system, the kernel programs are updated as much as possible under the condition of not interrupting original services, so as to support long-time and high-load operation of the operating system in an online environment. Namely, the hot update of the kernel program is realized under the condition of not interrupting the original service, and the method is very important for the use of an operating system. The hot update of the kernel program refers to a process of updating the kernel program without affecting the normal running of the operating system when the operating system runs.

In the related art, the reference count of the kernel program needs to be cleared first to unload the kernel program from the memory of the operating system, and then the new version of the kernel program is loaded to complete the update of the kernel program. Wherein, clearing the reference count requires shutting down all traffic associated with the kernel program, which causes the traffic to be interrupted, thereby resulting in the related art being unable to update the kernel program without interrupting the traffic. In addition, since the kernel program is completely unloaded, even after the loading of the new version of the kernel program is completed, it is difficult for the service to quickly restore to the original state.

In the embodiment of the application, the first kernel module is coupled with the service, and the second kernel module is decoupled from the service by splitting the kernel program into the first kernel module for receiving the service request and the second kernel module for interacting with the hardware device and supporting the first kernel module to interact with the hardware device through the second kernel module to process the service request. Therefore, the receiving of the service request and the state maintenance of the service can be realized by controlling the memory of the resident operating system of the first kernel module, and the updating of the kernel program is completed by updating the second kernel module, so that the user is free from feeling, and the kernel program is updated under the condition that the service is not interrupted (the service refers to the service needing to maintain the state in the updating process and can be specifically defined by the providers of different programs).

The technical scheme provided by the embodiment of the application mainly relates to the updating process of the kernel program, the execution main body of each step can be computer equipment, for example, the execution main body of each step can be an operating system in the computer equipment.

Reference is made to fig. 1, which is a schematic diagram of a computer device provided in one possible implementation of the present application.

The computer device 100 may be, for example, a server, a tablet computer, a multimedia playback device, a PC (Personal Computer ), an in-vehicle terminal device, a smart robot, a laptop portable computer, and any electronic device supporting an operating system deployment, to which embodiments of the application are not limited. The server may be a server, a server cluster formed by a plurality of servers, or a cloud computing service center.

The computer device 100 includes a hardware device 101, where the hardware device 101 may refer to a generic term for various physical devices in the computer device 100, where the physical devices are composed of electronic, mechanical, and optoelectronic elements, and the physical devices form an organic whole (i.e., a bare metal) according to a requirement of a system structure, and provide a material basis for running computer software.

By way of example, hardware device 101 may be implemented as at least one of a CPU (CentralProcessing Unit ), a graphics card (e.g., including a GPU (Graphics Processing Unit, image processor)), a memory, a hard disk, a motherboard, a power supply, a heat dissipation system, a display, a key pad, a mouse, an input device, an output device, and embodiments of the application are not limited in this respect.

An operating system 102 is installed on and runs on computer device 100. The operating system 102 may be stored in a hard disk of the computer device 100, and after the computer device 100 is turned on, the operating system 102 is loaded into a Memory of the computer device 100, such as a RAM (Random-Access Memory), which is also referred to as main Memory.

A kernel in operating system 102 may access hardware device 101 and provide an interface (e.g., an interface for system calls) to the outside. The operating system 102 enables different kernel programs to run normally and orderly by managing the kernels. Alternatively, operating system 102 may be implemented as a Linux system, as well as any other operating system (including a self-developed operating system), to which embodiments of the application are not limited.

The computer device 100 may also have an application 103 installed thereon for operation. Operating system 102 serves as an interactive bridge between application 103 and hardware device 101, and application 103 may use hardware device 101 by accessing an interface provided by the kernel through operating system 102. The application 103 is different from the kernel in the operating system 102, for example, the application 103 may be implemented as a user mode program as described above. The application 103 runs in a user space, and a user can directly interact with the application 103, and the application 103 can interact with a kernel (i.e., kernel program) through system calls. The kernel program runs in the kernel space for managing the meter hardware device 101.

By way of example, the application 103 may be implemented as at least one of a gaming type application, a social entertainment type application, an office type application, a video playback type application, a live broadcast type application, a shopping type application, and the present embodiments are not limited in this regard.

Optionally, the operating system 102 includes a program management module, where the program management module is a software resource, e.g., the program management module may be configured to perform at least one of installing a kernel, updating a kernel, upgrading a kernel, uninstalling a kernel, loading a kernel, and repairing a kernel. For example, the program management module may be implemented as a program update tool for use in the updating of kernel programs.

In an embodiment of the present application, the computer device 100 may update the kernel program through the operating system 102, and the operating system 102 may update the kernel program through the program management module. The update of the kernel program may be triggered by the user or may be triggered automatically by the operating system 102, which is not limited in this embodiment of the present application.

The technical scheme provided by the embodiment of the application is realized on the basis of splitting the kernel program, and a splitting method of the kernel program is explained below.

In the embodiment of the application, the computer equipment comprises an operating system, wherein the operating system comprises a program management module and a kernel program, and for any kernel program in the operating system, the kernel program can be split into two kernel modules, namely a first kernel module and a second kernel module.

The first kernel module resides in the memory of the operating system and directly interacts with an upper program, and the upper program can be at least one of a user mode program and other kernel programs. The first kernel module is used for providing basic functions of kernel programs so as to maintain the current state of the service. The basic functions of the kernel program may include at least one of an interactive function with an upper program (e.g., receiving a service request for a hardware device, sending a hardware device response, providing a system call (SYSTEM CALL), etc.), a call function of a callback function in the second kernel module, an export function of an export function.

The second kernel module is used for managing the hardware device, and maintains relevant interfaces for the hardware device. Optionally, the related interface is registered in the first kernel module in a callback form to meet the service requirement, so as to form a callback function in the second kernel module. Callback functions in the second kernel model may be used to interact with the hardware device. Wherein, unlike the disclosed export function, the callback function belongs to a private function, which needs to hold a corresponding private function pointer (which is not disclosed in kernel space, but only held by the first kernel module) to complete the call. While the export function may be implemented based on a published interface with its corresponding function pointer as published information (i.e., published in kernel space, all programs may hold).

The callback function in the second kernel module is not provided for other application programs, and the other application programs comprise at least one of other kernel programs and user state programs, wherein the user state programs are application programs in a user state when being executed. The other kernel programs may be any kernel program in the operating system except the kernel program to which the second kernel module belongs, that is, the callback function in the second kernel module is only provided to the kernel module in the kernel program to which the callback function belongs, for example, the first kernel module.

For example, the second kernel module only registers the callback function in the first kernel module to provide services to the first kernel module, but does not register the callback function in other application programs except the first kernel module, so that the other application programs can only indirectly interact with the second kernel module through the first kernel module to realize access of the hardware device.

In the embodiment of the application, the second kernel module does not directly interact with the upper layer program, but can indirectly interact with the upper layer program through the first kernel module, so that the second kernel module is decoupled from the upper layer program, and the update of the kernel program can be realized through updating the second kernel module under the condition of not interrupting service. Optionally, the second kernel module is not referred to by other kernel programs, so that the reference count is always zero for other kernel programs, which is beneficial to improving unloading convenience of the second kernel module, and the reference count of the second kernel module is cleared only for the first kernel module, which is beneficial to reducing unloading complexity of the second kernel module.

In one example, the first kernel module may be further operable to implement at least one of:

1. export functions of other kernel programs in the operating system are called.

The first kernel module may interact with other kernel programs by calling export functions of other kernel programs in the kernel space, thereby implementing function calls of the other kernel programs.

2. The method comprises the steps of providing a plurality of export functions for other application programs, wherein the other application programs comprise at least one of other kernel programs and user state programs, and the user state programs are application programs which are in user states when executed.

During installation of the first kernel module, the first kernel module exports a series of interfaces into kernel space to form an export function. For example, the first kernel module may export system calls into kernel space for disclosure to form export functions of the first kernel module. The export function of the first kernel module may be used for other applications to call the function of the first kernel module.

Other applications may interact with the first kernel module by calling an export function of the first kernel module, such as by calling an export function of the first kernel module through an interface corresponding to the export function of the first kernel module, to indirectly interact with the second kernel module.

3. The second kernel module is provided with a plurality of export functions.

The export function provided by the first kernel module to the second kernel module may be used to implement interaction of the first kernel module and the second kernel module. The plurality of export functions includes, illustratively, at least one of a first export function to register a private function pointer of the callback function in the first kernel module as empty, a third export function to register the callback function in the first kernel module, a second export function to store related data in the second kernel module to a storage unit of the operating system, and a fourth export function to transfer related data in the second kernel module from the storage unit of the operating system to a new storage unit applied for by an updated version of the second kernel module.

For example, the second kernel module may register the callback function in the first kernel module by calling the first export function or the third export function in the first kernel module, such as calling the first export function to register the private function pointer as empty to clear the callback function or calling the third export function to register the callback function in the first kernel module. The second kernel module may transfer related data with the first kernel module by calling a second export function or a fourth export function of the first kernel module, such as calling the second export function to restore related data or calling the fourth export function to acquire restored related data. The related data in the second kernel module may be data generated by interaction between the second kernel module and the hardware device, for example, data generated when a callback function in the second kernel module is executed, where the related data may include service data related to a service, a service state related to a service, and the like.

In one example, the first derived function and the third derived function may be implemented as the same derived function, such as integrating the third derived function into the first derived function, resulting in the first derived function being usable for registering the callback function. The second derived function and the fourth derived function may be implemented as the same derived function, e.g. integrating the fourth derived function in the second derived function results in the second derived function being usable for transmitting the relevant data.

According to the embodiment of the application, the first kernel module can interact with other application programs and the second kernel module respectively through supporting, so that the first kernel module can flexibly process service requests from other application programs by means of the second kernel module, and the flexibility of the first kernel module in processing services is improved.

For example, referring to fig. 2, the kernel program includes a first kernel module 201 and a second kernel module 202, where the first kernel module 201 resides in memory (i.e., is not unloaded), and is directly related to the service, such as the first kernel module 201 may interact with the user mode program 205 and other kernel programs 203, respectively. The second kernel module 202 is a main functional implementation of kernel programs that can interact directly with hardware devices 204, other kernel programs 203 that are service independent, etc. For example, the second kernel module 202 may call the export function of the other kernel program 203, but not provide callback functions to the other kernel program 203.

The second kernel module 202 may register a callback function with the first kernel module 201 through a third exporting function in the first kernel module 201. After the callback function registration is completed, the user mode program 205 may indirectly call the callback function registered by the second kernel module 202 through other derived functions (such as a system call) of the first kernel module 201 in the middle of the first kernel module 201, so as to indirectly interact with the second kernel module 202, thereby completing the service (implementing the access of the hardware device 204).

Alternatively, the other kernel 203 may also invoke the callback function registered by the second kernel 202 in the middle of the first kernel 201 through the export function in the first kernel 201.

In one example, the second kernel module may be divided into a plurality of sub-kernel modules having a hierarchical relationship from top to bottom. Each sub-kernel module may include at least one callback function, and different sub-kernel modules may have different callback functions to implement different functions or correspond to different hardware devices. The embodiment of the application does not limit the division mode of the sub-kernel module, and can be set and adjusted according to actual use requirements. Illustratively, the higher the frequency at which callback functions are called, the higher the hierarchy of the child kernel modules to which they are partitioned.

In the embodiment of the application, the hierarchy relation can be used for indicating the provision relation of the callback function, such as a low-level sub-kernel module, and is used for providing the callback function to a high-level sub-kernel module. Optionally, each sub-kernel module corresponds to a hierarchy. A top-down hierarchical relationship may refer to the closer a sub-kernel module is to a hardware device, the lower its hierarchy, in order of hierarchy from a user mode program to the hardware device. Any of the sub-kernel modules may be used to interact with the hardware device.

Illustratively, in the second kernel module, there is at least one sub-kernel module for providing the first kernel module with the callback function, and the sub-kernel module of the ith level is for providing the sub-kernel module of the i-1 level with the callback function. The callback function is used for interacting with the hardware device, i is an integer greater than 1, and the first level is the highest level in the hierarchical relationship.

Optionally, only the sub-kernel module of the first hierarchy provides the first kernel module with the callback function. The multiple kernel modules in the second kernel module can provide the callback function to the first kernel module, that is, the first kernel module can directly call the callback function in any sub-kernel module, or can indirectly call the callback function in the low-level sub-kernel function through the high-level sub-kernel function, which is not limited in the embodiment of the application.

Optionally, any level of the sub-kernel module can also provide a callback function for any sub-kernel module located at the upper layer of the sub-kernel module. The level of the sub-core module located at the upper layer of the sub-core module is higher than that of the sub-core module.

For example, referring to FIG. 3, the second kernel module 302 is divided into 2 sub-kernel modules, namely a sub-kernel module 1 and a sub-kernel module 2, wherein the sub-kernel module 1 and the kernel module 2 have a hierarchical relationship from top to bottom, and the sub-kernel module 2 can be used for providing the sub-kernel module 1 with the callback function. Alternatively, both the sub-kernel module 1 and the sub-kernel module 2 may provide the first kernel module 301 with the callback function. Both sub-kernel module 1 and sub-kernel module 2 may interact with hardware device 303.

For example, in the case where the user mode program 304 calls the export function of the first kernel module 301 through a system call, the first kernel module 301 may determine whether to call the callback function in the sub-kernel module 1 or call the callback function in the sub-kernel module 2 to process the system call request according to the system call request from the user mode program 304. In the case where the first kernel module 301 calls the callback function in the sub-kernel module 1, the hardware device 303 may be accessed through the callback function in the sub-kernel module 1, and in the case where the first kernel module 301 calls the callback function in the sub-kernel module 2, the hardware device 303 may be accessed through the callback function in the sub-kernel module 2.

Optionally, during the process that the callback function in the sub-kernel module 1 is called, the sub-kernel module 1 may also call the callback function in the sub-kernel module 2, which is not limited by the embodiment of the present application.

In one example, for any level of a sub-kernel module, it provides only one sub-kernel module located at an upper level of the sub-kernel module with its own callback function.

In an exemplary embodiment, the plurality of sub-core modules are distributed in a tree structure, where only the sub-core module of the first level provides the callback function to the first core module, and in a case that the first level corresponds to two sub-core modules, a first part of the sub-core modules in the second level are only used to provide the callback function to the first sub-core module of the first level, and a second part of the sub-core modules in the second level are only used to provide the callback function to the second sub-core module of the first level, and so on.

For a first sub-core module of a first level, a sub-core module which is positioned at the lower layer of the first sub-core module and is indirectly or directly connected with the first sub-core module forms a branch of the first sub-core module, and the first sub-core module is a root node of the branch. For any two branches, the sub-kernel modules between the two branches are not connected, i.e. there is no call relationship of callback functions.

According to the embodiment of the application, the second kernel module is split into the plurality of sub-kernel modules, so that the operating system can flexibly select the sub-kernel modules for updating according to requirements, the updating flexibility of the kernel program is facilitated, and the updating of part of the sub-kernel modules can be supported, and the whole second kernel module can be not required to be updated, thereby being beneficial to reducing the updating workload of the kernel program.

In addition, by setting the sub-kernel modules as a hierarchical relationship, management of the sub-kernel modules according to the hierarchical relationship can be realized, which is favorable for improving management convenience of kernel programs, and update of the sub-kernel modules according to the hierarchical relationship can be realized, which is favorable for reducing update complexity of the kernel programs.

In the embodiment of the application, since the first kernel module resides in the memory of the operating system, the function of the first kernel module is as concise and stable as possible, and the update (such as version iteration) of the kernel program is mainly realized on the second kernel module, so that the user can not feel the update of the kernel program by rapidly updating the second kernel module.

Optionally, by updating the second kernel module, updating operations such as version upgrade, repair, patching and the like for the kernel program can be realized. By updating part of the sub-kernel modules in the second kernel module, the repair and patching of the kernel program can be realized.

In summary, in the embodiment of the present application, the function for interaction in the kernel program is integrated into the first kernel module, and the function for managing the hardware device in the kernel program is integrated into the second kernel module. Therefore, the receiving of the service request and the state maintenance of the service can be realized by controlling the memory of the resident operating system of the first kernel module, and the updating of the kernel program is completed by updating the second kernel module, so that the user is free from feeling, and the updating of the kernel program under the condition of not interrupting the service is facilitated.

The method for updating the kernel program will be described in detail by using a method embodiment, and details not described in the method embodiment may refer to the above embodiment, which is not described herein.

Referring to fig. 4, a flowchart of a method for updating a kernel program provided in one possible implementation of the present application is shown. The subject of execution of the steps of the method may be a computer device as shown in fig. 1, such as an operating system in the computer device. The method may comprise at least one of the following steps (401-403).

Step 401, receiving a program update instruction, where the program update instruction is used to update a kernel program in an operating system, where the kernel program includes a first kernel module and a second kernel module, the first kernel module is used to receive a service request for a hardware device, and send a call request to the second kernel module according to the service request, and the second kernel module is used to interact with the hardware device to process the service request when receiving the call request.

In the embodiment of the present application, since the first kernel module needs to reside in the memory to implement the receiving of the service request and the state maintenance of the service, the program update instruction is essentially an instruction for triggering the update of the second kernel module. The program update instructions may be automatically triggered by the operating system and provided to a program management module in the operating system, such as in the event that a change in version of the kernel program is detected, the operating system automatically searches for an updated version of the kernel program (i.e., an updated version of the second kernel module) and downloads the updated version of the kernel program to the hard disk of the computer device. The operating system may generate program update instructions after compiling the updated version of the kernel program is completed, so as to notify the program management module in the operating system of the program update instructions, and the program management module completes the update of the kernel program. Alternatively, the program update instruction may also be generated by the operating system in the event that an update operation of the kernel program by the user is detected, which is not limited by the embodiment of the present application.

The service request for the hardware device may be a request to the hardware device to implement a specified function. The service request may be used to request to adjust a state of a display of the computer device (e.g., a resolution of the display, etc.), may be used to request to adjust a state of a GPU (e.g., a main frequency of the GPU), and may be used to request to adjust a state of a power supply of the computer device (e.g., a voltage of the power supply, etc.), which is not limited by the embodiments of the present application.

Alternatively, the service request may be sent to the first kernel module by another application. Other applications may include at least one of other kernel programs, user mode programs. For example, the other kernel program may send a service request to the first kernel module through an interface corresponding to the export function of the first kernel module to call the export function of the first kernel module. The user mode program may send a service request (i.e., a system call request) to the first kernel module through a system call of the first kernel module to call an export function of the first kernel module.

Service requests for the kernel program may be received and maintained by the first kernel module.

The call request may be used to call a second kernel module to interact with the hardware device. The target hardware device corresponding to the call request is the hardware device involved in processing the service request. The first kernel module can determine the target hardware device for processing the interaction required by the service by analyzing the service request, so as to call the second kernel module to interact with the target hardware device.

The second kernel module may include at least one callback function, and the call request may be used to call the callback function to interact with the hardware device. The second kernel module is used for interacting with the hardware device to process the service request under the condition that the call request is received. The call request may include a private function pointer registered by the callback function in the first kernel module, and the call of the callback function is implemented. For example, the first kernel module may determine a private function pointer for a target callback function interacting with the target hardware device by analyzing the service request, and generate a call request based on the private function pointer, where the private function pointer in the call request may be used to implement the call of the target callback function.

The callback function in the second kernel module is used for accessing the hardware device of the computer device. The second kernel module may be configured to provide the first kernel module with a callback function, so that the first kernel module may interact with the hardware device to process the service request by calling the callback function in the second kernel module. Callback functions for accessing the hardware devices can be deployed in the second kernel module.

Optionally, the program update instruction comprises at least one of identification information of a second kernel module currently in the operating system and identification information of an updated version of the second kernel module, and a finer version of the second kernel module is used for replacing the second kernel module. The identification information may be implemented as a version number of the second kernel module. The program management module in the operating system can unload the second kernel module and load the updated version of the second kernel module according to the program updating instruction. The updated version of the second kernel module is the updated version of the second kernel module.

Note that, in this embodiment, the second kernel module is not divided into a plurality of sub-kernel modules.

Step 402, uninstalling the second kernel module from the memory of the operating system.

Unloading the second kernel module from the memory of the operating system may refer to removing compiled data of the second kernel module from kernel space in order to free memory resources or to perform an update of the second kernel module.

Optionally, the operating system uninstalls the second kernel module from the memory of the operating system if the second kernel module is not invoked by the first kernel module. And calling the second kernel module is the call of the callback function in the second kernel module.

For example, the operating system may offload the second kernel module from memory of the operating system in the absence of a callback function in the second kernel module that is being invoked by the first kernel module. The operating system can execute the step of unloading the second kernel module from the memory of the operating system under the condition that the first kernel module does not call the callback function in the second kernel module, which is beneficial to avoiding influencing the current business related to the kernel program and further not influencing the use of a user.

In one example, before unloading the second kernel module, the operating system may flush the callback function registered by the second kernel module in the first kernel module to avoid an unloading process at the second kernel module, where the callback function is called, thereby avoiding a system failure. In addition, resources may be released to facilitate installation of the updated version of the second kernel module.

Illustratively, a first derived function of the first kernel module is invoked for registering at least one callback function as null in the respective corresponding private function pointers of the first kernel module. Alternatively, the operating system may notify the first kernel module to register the callback function in the second kernel module as empty by executing the second kernel module to call the first export function of the first kernel module.

Registering a callback function refers to associating the callback function with a private function pointer so as to call the callback function through the private function pointer. Registering a callback function as null may refer to modifying a private function pointer of the callback function in the second kernel module to point to a null function or a null function, so as to implement a call for clearing the callback function. After the callback function is registered as empty, the first kernel module can not call the callback function in the second kernel module through the private function pointer.

In the embodiment of the application, for any callback function in the second kernel module, before and after the private function pointer of the callback function is registered as empty, the private function pointer of the callback function is locked by the first kernel module.

For example, the first kernel module may add a write lock to the private function pointers of the callback function before and after modifying the private function pointers to ensure that no other threads are calling, modifying the private function pointers.

In an example, the embodiment of the application also supports the backup of the related data in the second kernel module, so as to ensure that the kernel program can quickly restore the service after being updated, and the user is free from feeling.

Illustratively, a second export function of the first kernel module is invoked for storing relevant data in the second kernel module to a storage unit of the operating system. Alternatively, the operating system may store the relevant data in the second kernel module to the memory unit of the operating system by executing the second kernel module to call the second export function of the first kernel module.

The related data are data generated by interaction between the second kernel module and the hardware equipment. Illustratively, the related data may include business data related to a business, business status related to a business, and the like.

Alternatively, the storage unit may be at least one of a memory and a magnetic disk. For example, the related data in the second kernel module may be backed up to the memory space applied by the first kernel module, or the related data in the second kernel module may be backed up to the disk space applied by the first kernel module.

Since the second kernel module is about to be unloaded, the applied memory space (or disk space) is about to be released, and therefore the second kernel module needs to rely on the second export function of the first kernel module to backup the related data. In the process of calling the second export function of the first kernel module and backing up the related data to the memory or the disk, the memory or the disk can be applied for a storage space according to the size of the related data, and the related data is copied to the applied storage space according to the input size from a pointer distributed for the related data.

For example, in the unloading process of the second kernel module, the service data may depend on the second export function of the first kernel module to temporarily store in the memory, and in the installation process of the updated version of the second kernel module, the service data may depend on the second export function (or the fourth export function) of the first kernel module again to restore to the new storage unit applied for by the updated version of the second kernel module.

For business data, the business data can be transferred to the first kernel module for management, and after the updated version of the second kernel module is installed, the business data can be continuously managed by the updated version of the second kernel module. If the service depends on an MMAP (Memory Map) system call to make a Memory Map, MUNMAP (Memory Unmap) needs to be avoided in the unloading process of the second kernel module, and the mapping relationship can be transferred to the first kernel module for management so as to maintain the state of the service.

Optionally, after the second kernel module finishes the related data backup and the callback function clearing, if the first kernel module is not calling the callback function in the second kernel module, the operating system may execute the step of unloading the second kernel module from the memory of the operating system, so as to release related resources (such as memory resources).

Alternatively, in the case where the second kernel module references other kernel programs, the operating system may directly dereference the second kernel module from the other kernel programs, such as suspending the second kernel module from invoking the export function of the other kernel programs.

According to the embodiment of the application, the service data is backed up through the first kernel module, so that the service can be quickly recovered by the updated version of the second kernel module, and the service state can be maintained through the first kernel module, so that the perception of the user on the update of the second kernel module can be reduced.

Optionally, before unloading the second kernel module is started and the updated version of the second kernel module is installed, the first kernel module no longer processes new service requests, thereby blocking service requests of other applications until the updated version of the second kernel module is installed. The first kernel module may wait in place for the updated version of the second kernel module to be installed, the waiting including at least one of spin, sleep. The notification means of the successful installation of the updated version of the second internal module comprises at least one of polling, condition variables.

Step 403, loading the updated version of the second kernel module into the memory of the operating system.

The operating system may load compiled data of the updated version of the second kernel module into the kernel space to complete installation of the updated version of the second kernel module. The updated version of the second kernel module is different from the second kernel module. For example, the version number of the updated version of the second kernel module is higher than the version number of the second kernel module, i.e. the updated version of the second kernel module is the new version and the second kernel module is the old version.

In one example, after loading the updated version of the second kernel module into the memory of the operating system, the operating system may call a third exporting function of the first kernel module for registering a callback function in the updated version of the second kernel module in the first kernel module, wherein after the updated version of the second kernel module is loaded, the first kernel module is configured to interact with the hardware device to process the service request by calling the callback function in the updated version of the second kernel module.

For example, the operating system may invoke the third export function of the first kernel module by executing the updated version of the second kernel module to associate the callback function in the updated version of the second kernel module with the private function pointer in the first kernel module, thereby enabling registration of the callback function in the updated version in the first kernel module. The callback function is a service specific implementation of the kernel program, for example, the callback function can be used for realizing at least one of the services of hardware device access, algorithm, memory management, disk management, interrupt service and the like. After the callback function in the updated version of the second kernel module is registered, the software stack corresponding to the kernel program is complete.

According to the embodiment of the application, the callback function is registered in the first kernel module by controlling the updated version of the second kernel module, so that the first kernel module can continue to perform service request processing through the updated version of the second kernel module, and the updating of the kernel program is completed. Since the main function of the kernel program is implemented in the second kernel module, updating the kernel program by quickly updating the second kernel module is not sensible to the end user. In addition, in the server scene, the server is not required to be restarted, so that the use of other users on the server is not affected.

In one example, after loading the updated version of the second kernel module into the memory of the operating system, the operating system may further call a fourth export function of the first kernel module, where the fourth export function is used to transfer related data in the second kernel module from a storage unit of the operating system to a new storage unit applied for by the updated version of the second kernel module, where after the transfer of the related data in the second kernel module is completed, the updated version of the second kernel module is used to continue processing the service request based on the related data.

For example, the operating system may call the fourth export function of the first kernel module by executing the updated version of the second kernel module to read the relevant data in the second kernel module from the memory unit of the operating system, and to dump the relevant data in the second kernel module to the new memory unit applied for by the updated version of the second kernel module.

The new storage unit may be a new memory space (or a new disk space) applied for by an updated version of the second kernel module, the first kernel module may transfer the flag and the pointer of the new storage unit into a fourth export function, and the fourth export function may copy the relevant data in the second kernel module to the transferred pointer according to the input size (i.e. the size of the relevant data) and the flag, so as to transfer the relevant data in the second kernel module to the new storage unit.

According to the embodiment of the application, the related data backed up by the first kernel module is restored to the updated version of the second kernel module, so that the kernel program can quickly restore the service processing capacity and the service of the kernel program can be quickly restored to the state before updating, thereby realizing continuous service provision.

The execution sequence of step 402 and step 403 is not limited in the embodiment of the present application. Illustratively, step 402 may be performed first and then step 403 may be performed, step 403 may be performed first and then step 402 may be performed, and step 402 and step 403 may be performed simultaneously.

In summary, according to the technical scheme provided by the embodiment of the application, the kernel program is split into the first kernel module for receiving the service request and the second kernel module for interacting with the hardware device, and the first kernel module is supported to interact with the hardware device through the second kernel module to process the service request, so that the first kernel module is coupled with the service, and the second kernel module is decoupled from the service. Therefore, the receiving of the service request and the state maintenance of the service can be realized by controlling the memory of the resident operating system of the first kernel module, and the updating of the kernel program is completed by updating the second kernel module, so that the user is free from feeling, and the kernel program is updated under the condition of not interrupting the service.

In some embodiments, where the second kernel module is divided into a plurality of sub-kernel modules having a hierarchical relationship from top to bottom, the offloading process of the second kernel module may further include the following.

1. And determining a target level according to the drive updating instruction, wherein the target level is the highest level to be unloaded in the second kernel module.

In the embodiment of the application, since a plurality of sub-kernel modules have a hierarchical relationship from top to bottom, the update of a sub-kernel module of a high level affects a sub-kernel module of a low level. Thus, the target level sub-kernel module may be offloaded along with the lower level sub-kernel modules associated with the target level sub-kernel module. The sub-kernel module associated with the sub-kernel module of the target level may refer to a sub-kernel module in which the callback function can be invoked by the sub-kernel module of the target level.

For example, since a certain block of the sub-kernel between the levels has a call relationship, a sub-kernel module of a higher level may call any sub-kernel module of a lower level, so if the sub-kernel module of the i level needs to be updated, all the sub-kernel modules located below the sub-kernel module of the i level need to be updated. If the s levels are the total, the i+1th level is the target level, then all the sub-kernel modules from the i+1th level to the s-th level need to be updated. If the ith level is the highest level child kernel module to be unloaded in the second kernel module, the ith level may be determined as the target level.

For example, referring to fig. 3, in the case of unloading only the sub-core module 2, since the sub-core module 2 is the sub-core module of the lowest hierarchy, only the sub-core module 2 needs to be unloaded, the hierarchy of the sub-core module 2 may be determined as a target hierarchy, in the case of unloading only the sub-core module 1, since the sub-core module 2 is the sub-core module of the highest hierarchy, the hierarchy of the sub-core module 1 may be determined as a target hierarchy, since the sub-core module 1 and the sub-core module 2 need to be simultaneously unloaded, and in the case of unloading the core module 1 and the core module 2, the hierarchy of the core module 1 is the highest, the hierarchy of the sub-core module 1 may be determined as a target hierarchy.

In one example, in the case that the plurality of sub-core modules are distributed in a tree structure, since the sub-core module of the target level only affects the branches taking the sub-core module of the target level as the root node, and other branches in the second core module are not affected, only the branches taking the sub-core module of the target level as the root node may be unloaded, and the branches taking the sub-core module of the target level as the root node may be updated. The sub-core modules in the branches are all related to the sub-core modules of the target level.

In this case, in the case that the target hierarchy corresponds to a plurality of sub-core modules, selection of a part of the sub-core modules in the target hierarchy for unloading is supported, which is not limited by the embodiment of the present application. For ease of illustration and understanding, embodiments of the present application will be described with respect to all sub-kernel modules at the lower level requiring offloading.

Alternatively, the drive update instruction may include a target tier, from which the operating system may directly obtain the target tier. The driver update instruction may also include a hierarchy of each sub-kernel module to be offloaded, where the operating system may determine a target hierarchy from the hierarchies included in the driver update instruction, which is not limited in the embodiment of the present application.

2. And unloading all the sub-kernel modules in the second kernel module from the memory of the operating system in sequence according to the hierarchical sequence from bottom to top from the lowest hierarchy in the hierarchical relationship until the unloading of the sub-kernel modules of the target hierarchy is completed.

The lowest hierarchy is the hierarchy closest to the hardware device, and the bottom-up hierarchy order is the order from the hardware device to the first kernel module. In the case that the sub-kernel module of the target level is unloaded, it may be determined that the unloading task of the second kernel module is completed.

Illustratively, in the case where the ith hierarchy is the target hierarchy, if there are s hierarchies in total, unloading may be started from the sub-core module of the ith hierarchy in the order of the hierarchy from the lowest hierarchy in the hierarchy relationship from the bottom to the top until the unloading of the sub-core module of the ith hierarchy is completed. After the s-th level sub-kernel module is unloaded, the operating system starts to execute the unloading of the s-1-th level sub-kernel module.

For example, referring to fig. 3, in the case where both the sub-kernel module 1 and the sub-kernel module 2 need to be unloaded, the sub-kernel module 2 may be unloaded from the memory of the operating system first, and then the sub-kernel module 1 is unloaded from the memory of the operating system, and resources occupied by the sub-kernel module 1 and the sub-kernel module 2 are sequentially released, so as to complete the unloading of the second kernel module 302.

The embodiment of the application supports the unloading of only part of the sub-kernel modules in the second kernel module, thereby being beneficial to reducing the unloading workload of the second kernel module. In addition, the sub-kernel modules are unloaded sequentially according to the hierarchical sequence from bottom to top, so that the unloading complexity of the sub-kernel modules is reduced.

In one example, in the case where the second core module is divided into a plurality of sub-core modules having a hierarchical relationship from top to bottom, the data backup process of the second core module may further include the following.

1. And determining a sub-kernel module to be unloaded in the second kernel module based on the target level to obtain a module unloading set.

A module offload set is a set or sequence of child kernel modules to be offloaded.

For example, all sub-kernel modules with a hierarchy lower than the target hierarchy may be determined as sub-kernel modules to be offloaded, and the sub-kernel modules to be offloaded are combined to obtain a module offloaded set.

For example, referring to fig. 3, in the case where the target hierarchy is the hierarchy of the sub-core module 1, both the sub-core module 1 and the sub-core module 2 may be determined as sub-core modules to be offloaded, and the sub-core module 1 and the sub-core module 2 may be combined to obtain a module offload set.

2. And storing related data corresponding to the module unloading set to a storage unit of the operating system through the sub-kernel modules which are not unloaded in the first kernel module or the second kernel module according to the sequence of the hierarchy from bottom to top from the lowest hierarchy in the hierarchy relation.

And carrying out backup on related data of each sub-kernel module to be unloaded in sequence according to the hierarchical sequence from bottom to top. Illustratively, in the case where the ith hierarchy is the target hierarchy, if there are s hierarchies in total, backup may be started from the lowest hierarchy in the hierarchy relation, in the order of hierarchy from bottom to top, from the relevant data in the child kernel module of the ith hierarchy until the child kernel module of the ith hierarchy is completed for backup of the relevant data. After the s-th level sub-kernel module is backed up, the operating system starts to backup the related data in the s-1-th level sub-kernel module.

The relevant data corresponding to the module unloading set comprises relevant data of each sub-kernel module to be unloaded in the module unloading set. In an embodiment, the storage unit of the operating system may include at least one of a storage space (such as a memory space and a disk space) applied by the first kernel module and a storage space applied by the unloaded sub-kernel module.

Optionally, for any of the sub-core modules to be offloaded in the module offloaded set, the sub-core module to be offloaded may call a second export function of the first core module to directly store the relevant data into the memory space applied for by the first core module, the sub-core module to be offloaded may call an export function of the sub-core module not to be offloaded to directly store the relevant data into the memory space applied for the sub-core module not to be offloaded, the sub-core module to be offloaded may also store a portion of the relevant data into the memory space applied for by the first core module, and a remaining portion of the relevant data into the memory space applied for by the sub-core module not to be offloaded, and the sub-core module to be offloaded may also store the relevant data into the target sub-core module to be offloaded, where the target sub-core module to be offloaded is stored into the memory space applied for the first core module or the memory space applied for the sub-core module not to be offloaded. The embodiment of the application does not limit the backup mode of the related data. The non-unloaded sub-kernel modules can comprise sub-kernel modules which do not need to be unloaded and sub-kernel modules which need to be unloaded but are not unloaded. Sub-kernel modules that need to be offloaded, but not offloaded, may be used for transition transfer of relevant data.

For example, referring to fig. 3, in the case where only the sub-core module 2 is unloaded, the relevant data in the sub-core module 2 may be stored in the memory space applied for by the sub-core module 1, the relevant data in the sub-core module 2 may be stored in the memory space applied for by the first core module 301, or the relevant data in the core module 2 may be stored in part in the memory space applied for by the sub-core module 1, and in part in the memory space applied for by the first core module 301.

Under the condition that the sub-core module 1 and the sub-core module 2 are required to be unloaded, the sub-core module 2 is unloaded first, and then the sub-core module 1 is unloaded. The backup scheme of the related data in the sub-core module 2 may be the same as the backup scheme described above, and will not be described here again.

For the sub-core module 1, when the relevant data in the sub-core module 2 is stored in the memory space applied by the sub-core module 1, the relevant data in the sub-core module 2 and the relevant data in the sub-core module 1 may be stored in the memory space applied by the first core module 301, and when the relevant data in the sub-core module 1 is stored in the memory space applied by the sub-core module 1, the relevant data in the sub-core module 1 may be stored in the memory space applied by the first core module 301.

According to the embodiment of the application, the related data of the sub-kernel module to be unloaded is backed up according to the hierarchical sequence from bottom to top, so that the backup integrity of the related data is ensured. In addition, the related data are backed up sequentially according to the hierarchical sequence from bottom to top, so that the backup complexity of the related data is reduced.

In one example, where the second kernel module is divided into a plurality of sub-kernel modules having a top-down hierarchical relationship, the operating system may sequentially register the private function pointers of the callback functions in the sub-kernel modules in the target kernel module of the sub-kernel module as empty in a bottom-up hierarchical order, starting from the lowest level in the hierarchical relationship, until the purging of the callback functions in the sub-kernel module of the target level is completed.

The target kernel module of the sub-kernel module comprises at least one of a first kernel module and a sub-kernel module positioned on the upper layer of the sub-kernel module. For example, for the ith level of sub-kernel module, it may register its callback function in the first kernel module, or may register its callback function in any of the ith-1 level of sub-kernel module to the first level of sub-kernel module, so the first kernel module or the sub-kernel module located at the upper layer of the sub-kernel module may be determined as the target kernel module of the ith level of sub-kernel module.

Under the condition of unloading the sub-kernel module of the ith level, corresponding private function pointers of callback functions in the target kernel module are required to be modified to point to a null function or a null operation function so as to empty the callback functions. Illustratively, the callback function may be registered as null by the export function of the target kernel module. For example, for a first kernel module, its callback function may be registered as empty by calling a first export function of the first kernel module, and for a sub-kernel module located at an upper layer, its callback function may be registered as empty by calling an export function of the sub-kernel module located at the upper layer. After the callback function in the sub-kernel module of the ith level is cleared (i.e. registered as empty), executing to clear the callback function in the sub-kernel module of the ith-1 level until the clearing of the callback function in the sub-kernel module of the target level is completed.

For example, referring to fig. 3, in the case where both the sub-kernel module 1 and the sub-kernel module 2 need to be unloaded, the callback functions registered in the first kernel module 301 and the sub-kernel module 1 by the sub-kernel module 2 may be registered as empty, and then the callback functions registered in the first kernel module 301 by the sub-kernel module 1 may be registered as empty, so as to complete the clearing of the callback functions.

According to the embodiment of the application, the callback functions of the sub-kernel modules to be unloaded are sequentially cleared according to the hierarchical sequence from bottom to top, so that the clearing integrity of the callback functions is ensured. In addition, the callback functions are sequentially cleared according to the hierarchical sequence from bottom to top, so that the clearing complexity of the callback functions is reduced.

In some embodiments, in the case where the second kernel module is divided into a plurality of sub-kernel modules having a hierarchical relationship from top to bottom, for the loading process of the updated version of the second kernel module, the embodiments of the present application may further include the following.

The operating system may start with a new sub-kernel module of the target hierarchy in the updated version of the second kernel module, and load the new sub-kernel module in the updated version of the second kernel module into the memory of the operating system sequentially according to the hierarchy order from top to bottom.

For example, in the case where the ith hierarchy is the target hierarchy, if s hierarchies are altogether, loading may be started from the new child kernel module of the ith hierarchy in the order from top to bottom until loading of the new child kernel module of the ith hierarchy is completed. After the new sub-kernel module of the ith level is loaded, the operating system starts to execute the loading of the new sub-kernel module of the (i+1) th level until the loading of the new sub-kernel module of the(s) th level is completed.

For example, referring to fig. 3, in the case where both the sub-kernel module 1 and the sub-kernel module 2 need to be unloaded, a new sub-kernel module 1 corresponding to the sub-kernel module 1 may be loaded into the memory of the operating system, and then a new sub-kernel module 2 corresponding to the sub-kernel module 2 may be loaded into the memory of the operating system, so as to complete the loading of the updated version of the second kernel module corresponding to the second kernel module 302.

The embodiment of the application supports only updating part of the sub-kernel modules in the second kernel module, which is beneficial to reducing the loading workload of the second kernel module. In addition, the new sub-kernel modules are loaded in sequence according to the hierarchical sequence from top to bottom, so that the loading complexity of the new sub-kernel modules is reduced, and the hierarchical relation among the new sub-kernel modules is maintained.

In one example, in the case where the second core module is divided into a plurality of sub-core modules having a hierarchical relationship from top to bottom, the data recovery process of the second core module may further include the following.

1. And determining a new sub-kernel module to be loaded in the updated version of the second kernel module based on the target level to obtain a module loading set.

The module load set is a set or sequence of new sub-kernel modules to be loaded.

For example, all new sub-kernel modules with the hierarchy lower than the target hierarchy may be determined as new sub-kernel modules to be loaded, and the new sub-kernel modules to be loaded are combined to obtain a module loading set.

For example, referring to fig. 3, in the case where the target hierarchy is the hierarchy of the sub-core modules 1, a new sub-core module 1 corresponding to the sub-core module 1 and a new sub-core module 2 corresponding to the sub-core module 2 may be determined as a new sub-core module to be loaded, and the new sub-core module 1 and the new sub-core module 2 may be combined to obtain the module load set.

2. And starting from a new sub-kernel module of the target level in the updated version of the second kernel module, and sequentially recovering the related data in the storage unit of the operating system to each new sub-kernel module in the module loading set according to the level sequence from top to bottom.

And recovering the related data of each new sub-kernel module to be loaded in turn according to the hierarchical sequence from top to bottom. For example, in the case where the ith hierarchy is the target hierarchy, if s hierarchies are altogether, the recovery may be started from the related data in the child kernel module of the ith hierarchy until the related data in the child kernel module of the ith hierarchy is recovered in the order of hierarchy from top to bottom. The related data in the ith sub-kernel module can be recovered from the storage unit of the operating system to the new memory space applied by the ith new sub-kernel module. After the recovery of the related data is completed for the sub-kernel module of the i-th level, the operating system starts to recover the related data in the sub-kernel module of the i+1-th level.

In this embodiment, the storage unit of the operating system may include at least one of a storage space (e.g., a memory space and a disk space) applied by the first kernel module and a storage space applied by the unloaded sub-kernel module.

The restoration process of the related data corresponds to the backup process of the related data. Taking the ith level as an example, under the condition that the related data in the ith level of sub-kernel module is all stored in the memory space applied by the first kernel module, the fourth export function of the first kernel module can be directly called to restore the related data in the ith level of sub-kernel module to the new memory space applied by the ith level of new sub-kernel module, and so on until the related data in the s level of sub-kernel module is restored to the new memory space applied by the s level of new sub-kernel module from the memory space applied by the first kernel module.

The operating system can restore the related data from the ith+1 level sub-kernel module to the s level sub-kernel module to the new memory space applied by the ith level new sub-kernel module, so that the related data from the ith+1 level sub-kernel module to the s level sub-kernel module can be restored to the new memory space applied by the ith+1 level new sub-kernel module from the new memory space applied by the ith level sub-kernel module, and so on until the related data in the s level sub-kernel module is restored to the new memory space applied by the s level new sub-kernel module from the s-1 level new memory space applied by the s level new sub-kernel module.

Under the condition that the related data in the ith-level sub-kernel module is stored in the memory space applied by the unloaded sub-kernel module, the export function of the unloaded sub-kernel module can be directly called, the related data in the ith-level sub-kernel module is restored to the new memory space applied by the ith-level new sub-kernel module, and so on until the related data in the s-level sub-kernel module is restored to the new memory space applied by the s-level new sub-kernel module from the memory space applied by the unloaded sub-kernel module.

The operating system may also restore the related data in the i+1 level sub-kernel module to the s level sub-kernel module from the memory space applied by the unloaded sub-kernel module to the new memory space applied by the i level new sub-kernel module, so that the related data in the i+1 level sub-kernel module to the s level sub-kernel module may be restored from the new memory space applied by the i level new sub-kernel module to the new memory space applied by the i+1 level new sub-kernel module, and so on, until the related data in the s level sub-kernel module is restored from the new memory space applied by the s-1 level new sub-kernel module to the new memory space applied by the s level new sub-kernel module.

In the case where the partial related data of the ith-level sub-core module is stored in the memory space applied for by the first core module and the remaining related data of the ith-level sub-core module is stored in the memory space applied for by the sub-core module that is not unloaded, the partial related data of the ith-level sub-core module may be restored from the memory space applied for the first core module to the memory space applied for the ith-level new sub-core module and the remaining related data of the ith-level sub-core module may be restored from the memory space applied for the sub-core module that is not unloaded to the memory space applied for the ith-level new sub-core module. The embodiment of the application does not limit the recovery mode of the related data.

For example, referring to fig. 3, in the case of unloading only the sub-core module 2, if the relevant data in the sub-core module 2 is stored in the memory space applied by the sub-core module 1 entirely, the relevant data in the sub-core module 2 may be restored to the new memory space applied by the new core module 2 by calling the export function of the sub-core module 1.

If the relevant data in the sub-kernel module 2 is stored in the memory space applied by the first kernel module 301, the relevant data in the sub-kernel module 2 can be restored to the new memory space applied by the new kernel module 2 by calling the fourth export function of the first kernel module 301.

If the relevant data in the kernel module 2 is partially stored in the memory space applied by the sub-kernel module 1 and the remaining part is stored in the memory space applied by the first kernel module 301, the relevant data of the sub-kernel module 2 may be restored to the new memory space applied by the new kernel module 2 by calling the export function of the sub-kernel module 1, and the relevant data of the remaining part of the sub-kernel module 2 may be restored to the new memory space applied by the new kernel module 2 by calling the fourth export function of the first kernel module 301.

Under the condition that the sub-kernel module 1 and the sub-kernel module 2 are required to be unloaded, the related data in the sub-kernel module 1 can be recovered from the new memory space applied by the first kernel module 301 to the new memory space applied by the new kernel module 1, and then the related data in the sub-kernel module 2 can be recovered from the new memory space applied by the first kernel module 301 to the new memory space applied by the new kernel module 2.

The related data in the sub-core module 1 and the related data in the sub-core module 2 may be recovered from the new memory space applied by the first core module 301 to the new memory space applied by the new core module 1, and the related data in the sub-core module 2 may be recovered from the new memory space applied by the new core module 1 to the new memory space applied by the new core module 2.

According to the embodiment of the application, the related data of the unloaded sub-kernel module is recovered according to the hierarchical sequence from top to bottom, so that the recovery integrity of the related data is ensured, and the service is quickly recovered. In addition, the related data are sequentially restored according to the hierarchical sequence from top to bottom, so that the restoration complexity of the related data is reduced.

In one example, where the second kernel module is divided into a plurality of sub-kernel modules having a hierarchical relationship from top to bottom, the callback function registration process of the updated version of the second kernel module may further include the following.

The operating system may start with a new sub-kernel module of the target hierarchy in the updated version of the second kernel module, and sequentially register callback functions in the new sub-kernel module in the target kernel module of the new sub-kernel module according to a hierarchy order from top to bottom.

The target kernel module of the new kernel module comprises at least one of a first kernel module, a new kernel module positioned at the upper layer of the new kernel module and a kernel module positioned at the upper layer of the new kernel module.

For example, taking the ith level as the target level, for the new sub-kernel module of the ith level, the callback function may be registered in the first kernel module, or the callback function may be registered in any one of the sub-kernel modules from the ith-1 level to the first level, so that the first kernel module or the sub-kernel module located at the upper layer of the new sub-kernel module of the ith level may be determined as the target kernel module of the new sub-kernel module of the ith level.

After the callback function in the new child kernel module of the ith hierarchy is registered, the operating system starts to register the callback function in the new child kernel module of the (i+1) th hierarchy. For the new sub-kernel module of the i+1 level, the callback function may be registered in the first kernel module, the callback function may be registered in the new sub-kernel module of the i level, and the callback function may be registered in any one of the sub-kernel modules of the i-1 level to the first level, which is not limited in this embodiment of the present application.

And so on until the callback function in the new child kernel module of the s-th level is registered. For the new sub-kernel module of the s-th level, the callback function may be registered in the first kernel module, or may be registered in any one of the new sub-kernel modules of the s-1-th level to the i-th level, or may be registered in any one of the sub-kernel modules of the i-1-th level to the first level, which is not limited in the embodiment of the present application.

For example, referring to fig. 3, in the case where both the sub-kernel module 1 and the sub-kernel module 2 need to be unloaded, the callback function in the new sub-kernel module 1 may be registered in the first kernel module 301 first, and then the callback function in the new sub-kernel module 2 may be registered in the first kernel module 301 or in the new sub-kernel module 1.

According to the embodiment of the application, the callback functions of the new sub-kernel module are registered sequentially according to the hierarchical sequence from top to bottom, so that the registration order of the callback functions is ensured. In addition, by registering callback functions in sequence according to the hierarchical order from top to bottom, the registration complexity of the callback functions is reduced, and the provision relation among the callback functions is maintained.

In some embodiments, for the installation process of the first kernel module and the second kernel module, the embodiments of the present application may further include the following.

In the embodiment of the application, the first kernel module is installed first, and the second kernel module is installed after the first kernel module is installed.

1. During loading of the first kernel module, exporting a plurality of export functions of the first kernel module to a kernel space of an operating system, the plurality of export functions of the first kernel module including a third export function for registering callback functions with the first kernel module.

Alternatively, export of the export function may be accomplished by exporting an interface of the export function into kernel space. Other applications may call the export function through its interface.

The third derived function, when invoked, may be used to modify the private function pointer in the first kernel module to complete registration of the callback function. The third export function performs a locking operation (e.g., write lock) on the private function pointers before and after modifying the private function pointers to ensure that no other threads are calling and modifying the private function pointers.

Optionally, the export functions of the first kernel module may further include a second export function and a fourth export function for exchanging related data of the second kernel module. The second export function may be used to backup data and the fourth export function may be used to restore data. In backing up data, the second export function may apply for storage space to the memory or disk according to the size of the incoming data, and copy the data from the pointer to the applied storage space according to the size of the incoming data. In recovering the data, the fourth export function may copy the specified data to the incoming pointer (as may be provided by the updated version of the second kernel module) according to the incoming size and tag.

Alternatively, if the first kernel module also references other kernel modules, the first kernel module may be classified as a service provider or a served party. In the case that the first kernel module is a service provider, the first kernel module may register related callback functions with other kernel programs through derived functions of the other kernel programs. Export functions may also be provided to other kernel programs for other kernel program calls.

In the case where the first kernel module is the served party, it may initiate the service request by calling a callback function or an export function or the like registered by other kernel programs.

2. And in the process of loading the second kernel module, calling a third derived function to register a callback function in the second kernel module in the first kernel module.

For example, the operating system may invoke the third export function of the first kernel module by executing the second kernel module to associate the callback function in the second kernel module with the private function pointer in the first kernel module, thereby implementing registration of the callback function in the second kernel module in the first kernel module. The callback function is a service specific implementation of the kernel program, such as at least one of services of hardware device access, algorithm, memory management, disk management, interrupt service and the like. After the callback function in the second kernel module is registered, the software stack corresponding to the kernel program is complete.

3. And initializing a second kernel module.

Initializing the second kernel module may refer to initializing parameters in the second kernel module according to a state of a hardware device, and exposing services that can be provided by the second kernel module to other application programs, such as a user mode program, other kernel programs, and the like. These services may be services that are not much related to business, or services that a developer can ensure will not be accessed when updating a kernel program, such as kernel Debug services (Debug FILE SYSTEM, debugfs), and the like.

In one example, after the kernel program is installed, in a case that a first function in the first kernel module is called by a process of the user mode program, the first kernel module calls a first callback function indicated by the first private function pointer in the second kernel module according to the first private function pointer determined by the first function, so as to return an execution result of the first callback function to the process of the user mode program.

The first function may be any derived function or any callback function of the first kernel module. For example, the process of the user mode program may call the first function in the first kernel module through a system call, for example, through a system call interface, and send a system call request (i.e., the service request described above) to the first kernel module to implement the call of the first function.

If the first function needs to call the first callback function in the second kernel module to process the system call request, the first callback function in the second kernel module can be called through a first private function pointer (such as the call request) pointing to the first callback function. The execution result of the first callback function may be a response result of the hardware device.

Before and after the first callback function is called, the first private function pointer is locked by the first kernel module, and the user state program is an application program in a user state when being executed.

Optionally, during the process of providing services for the kernel program, the user mode program may initiate a specific service request to the second kernel module through the first kernel module, for example, may initiate a series of service requests to the first kernel module through a system call such as call open, read, write, ioctl. The first kernel module can call a callback function registered by the second kernel module to process the service request, so that the user mode program can indirectly initiate a specific service request to the second kernel module through the first kernel module. When the first kernel module calls the callback function in the second kernel module, locks (such as adding a read lock) are added to the private function pointers of the callback function before and after the callback function is called, so that no other thread is modifying the private function pointers.

Under the condition that the first kernel module also refers to other kernel programs, if the first kernel module is a service provider, the user state program may initiate system call to the other kernel programs to initiate a request to the first kernel module through a callback function in the first kernel module, and then initiate a specific service request to the second kernel module. The other kernel programs can be multiple, call relations exist among the kernel programs, the generalized form can be unified into a user mode program to initiate service requests to the other kernel programs, and the service requests are sent to the first kernel module.

The second kernel module must no longer act as a service provider for other kernel programs, but may act as a served side for other kernel programs. If the second kernel module refers to other kernel programs and serves as a served party, after the business process goes from the user mode program to the second kernel module, the second kernel module may call export functions of the other kernel programs to initiate a series of services.

According to the embodiment of the application, the first kernel module and the second kernel module are sequentially installed, so that the hierarchical relationship between the first kernel module and the second kernel module can be ensured, and the first kernel module can process the service request based on the second kernel module.

In addition, by integrating the function for managing the hardware device in the kernel program into the second kernel module and supporting the first kernel module to call the callback function of the second kernel module to process the service request, the second kernel module is decoupled from the service under the condition of ensuring the function realization of the kernel program, which is beneficial to realizing the update of the kernel program without interrupting the service by updating the second kernel module.

In some embodiments, a kernel driver is implemented as a kernel program, which is used to describe a technical solution provided by an embodiment of the present application.

The kernel driver may be used to control and manage the hardware device, which may be used to pass requests of the user mode program to the hardware device, and return responses of the hardware device to the processes of the user mode program.

Referring to fig. 2 and 5, in the case where the kernel driver is split into the first kernel module 201 and the second kernel module 202, the update process of the kernel driver may include the following.

1. The callback function registered in the first kernel module 201 by the second kernel module 202 is emptied by calling the first export function of the first kernel module 201.

2. The related data in the second kernel module 202 is transferred to the memory space applied by the first kernel module 201 by calling the second export function of the first kernel module 201.

3. In the event that the first kernel module 201 does not call a callback function in the second kernel module 202, the second kernel module 202 is uninstalled from the kernel space of the operating system.

Alternatively, the uninstall operation is not performed on the first kernel module 201.

4. After the offloading of the second kernel module 202 is completed, the updated version of the second kernel module 202 is loaded into the kernel space of the operating system.

5. The callback function in the updated version of the second kernel module 202 is registered in the first kernel module 201 by calling the third export function of the first kernel module 201.

6. The related data in the second kernel module 202 is restored from the memory space applied by the first kernel module 201 to the new memory space applied by the updated version of the second kernel module 202 by calling the fourth export function of the first kernel module 201.

7. The first kernel module 201 interacts with the hardware device 204 through callback functions in the updated version of the second kernel module 202 to process the service request.

Referring to fig. 3 and 6, in the case where the kernel driver is split into the first kernel module 301 and the second kernel module 302, and the second kernel module 302 is further split into the sub-kernel module 1 and the sub-kernel module 2, taking the case where both the sub-kernel module 1 and the sub-kernel module 2 need to be offloaded, the update process of the kernel driver may include the following.

1. The callback function registered in the sub-kernel module 1 by the sub-kernel module 2 is emptied by calling the first exporting function of the first kernel module 301 and by calling the exporting function of the sub-kernel module 1.

2. The related data in the sub-kernel module 2 is transferred to the memory space applied by the sub-kernel module 1 by calling the export function of the sub-kernel module 1.

3. In the event that the first kernel module 201 does not call a callback function in the second kernel module 202, the sub-kernel module 2 is uninstalled from the kernel space of the operating system.

4. After the unloading of the sub-kernel module 2 is completed, the callback function registered in the first kernel module 301 by the sub-kernel module 1 is emptied by calling the first export function of the first kernel module 301.

5. The related data in the sub-core module 1 and the related data in the sub-core module 2 are transferred from the memory space applied by the sub-core module 1 to the memory space applied by the first core module 301 by calling the second derivative function of the first core module 301.

6. The sub-kernel module 1 is offloaded from the kernel space of the operating system.

7. After the unloading of the sub-kernel module 1 is completed, the new sub-kernel module 1 is loaded into the kernel space of the operating system.

The new sub-core module 1 is an updated version of the sub-core module 1, and the new sub-core module 2 is an updated version of the sub-core module 2.

8. And restoring the related data in the sub-core module 1 and the related data in the sub-core module 2 from the memory space applied by the first core module 301 to the new memory space applied by the new sub-core module 1 by calling the third derived function of the first core module 301 to register the callback function in the new sub-core module 1 in the first core module 301 and calling the fourth derived function of the first core module 301.

9. After the installation of the new sub-kernel module 1 is completed, the new sub-kernel module 2 is loaded into the kernel space of the operating system.

10. The callback function in the new sub-kernel module 2 is registered in the first kernel module 301 by calling the third derived function of the first kernel module 301, and the callback function in the new sub-kernel module 2 is registered in the sub-kernel module 1 by calling the derived function of the new sub-kernel module 1.

11. The related data in the sub-kernel module 2 is restored to the new memory space applied by the new sub-kernel module 2 from the new memory space applied by the new sub-kernel module 1 by calling the export function of the new sub-kernel module 1.

12. The first kernel module 301 interacts with the hardware device 303 through callback functions in the new sub-kernel module 1 or the new sub-kernel module 2 to process the service request.

In summary, according to the technical scheme provided by the embodiment of the application, the kernel driver is split into the first kernel module for receiving the service request and the second kernel module for providing the callback function, and the first kernel module is supported to interact with the hardware device through the callback function in the second kernel module to process the service request, so that the first kernel module is coupled with the service, and the second kernel module is decoupled from the service. Therefore, the memory of the resident operating system of the first kernel module can be controlled, the receiving of the service request and the state maintenance of the service are realized, and the updating of the kernel program is completed by updating the second kernel module, so that the user is free from feeling, and the kernel driver is updated under the condition of not interrupting the service.

The following are examples of the apparatus of the present application that may be used to perform the method embodiments of the present application. For details not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the method of the present application.

Referring to FIG. 7, a block diagram of an update apparatus for a kernel program provided in one possible implementation of the present application is shown. The device has the function of realizing the method example, and the function can be realized by hardware or can be realized by executing corresponding software by hardware. The apparatus may be the computer device described above or may be provided in a computer device. As shown in fig. 7, the apparatus 700 includes an update instruction receiving module 701, a kernel module unloading module 702, and a kernel module loading module 703.

The update instruction receiving module 701 is configured to receive a program update instruction, where the program update instruction is configured to update a kernel program in an operating system, where the kernel program includes a first kernel module and a second kernel module, the first kernel module is configured to receive a service request for a hardware device, and send a call request to the second kernel module according to the service request, and the second kernel module is configured to interact with the hardware device to process the service request when receiving the call request.

And the kernel module uninstallation module 702 is configured to uninstall the second kernel module from the memory of the operating system.

The kernel module loading module 703 is configured to load the updated version of the second kernel module into the memory of the operating system.

In some embodiments, the second kernel module includes at least one callback function, the call request is used for calling the callback function to interact with the hardware device, and the kernel module uninstall module 702 is used for uninstalling the second kernel module from the memory of the operating system if the callback function which is being called by the first kernel module does not exist in the second kernel module.

In some embodiments, as shown in FIG. 8, the apparatus 700 further comprises a callback function clearing module 704.

And a callback function flushing module 704, configured to call a first derived function of the first kernel module, where the first derived function is configured to register private function pointers of the at least one callback function corresponding to the first kernel module as null, where, for any callback function in the second kernel module, before and after the private function pointers of the callback function are registered as null, the private function pointers of the callback function are executed by the first kernel module.

In some embodiments, as shown in FIG. 8, the apparatus 700 further comprises a related data backup module 705.

And the related data backup module 705 is configured to call a second export function of the first kernel module, where the second export function is configured to store related data in the second kernel module to a storage unit of the operating system, where the related data is data generated by interaction between the second kernel module and the hardware device.

In some embodiments, the callback function in the second kernel module is not provided for other application programs, and the other application programs comprise at least one of other kernel programs and user state programs, wherein the user state programs are application programs in a user state when being executed.

In some embodiments, the first kernel module is further configured to implement at least one of:

calling export functions of other kernel programs in the operating system;

providing a plurality of export functions for other application programs, wherein the other application programs comprise at least one of other kernel programs and user state programs, and the user state programs are application programs in user states when executed;

The plurality of export functions are provided to the second kernel module.

In some embodiments, as shown in FIG. 8, the apparatus 700 further comprises a callback function registration module 706.

And a callback function registration module 706, configured to call a third export function of the first kernel module, where the third export function is configured to register a callback function in an updated version of the second kernel module in the first kernel module, and after the updated version of the second kernel module is loaded, the first kernel module is configured to interact with the hardware device to process the service request by calling the callback function in the updated version of the second kernel module.

In some embodiments, as shown in FIG. 8, the apparatus 700 further comprises a related data recovery module 707.

And the related data recovery module 707 is configured to call a fourth export function of the first kernel module, where the fourth export function is configured to transfer related data in the second kernel module from a storage unit of the operating system to a new storage unit applied for by an updated version of the second kernel module, where after the related data in the second kernel module is transferred, the updated version of the second kernel module is used to continue processing the service request based on the related data.

In some embodiments, the second kernel module is divided into a plurality of sub-kernel modules having a hierarchical relationship from top to bottom, in which there is at least one sub-kernel module for providing the first kernel module with a callback function, the i-th level sub-kernel module for providing the i-1-th level sub-kernel module with a callback function, the callback function for interacting with the hardware device, i being an integer greater than 1, the kernel module offload module 702 being further configured to:

determining a target level according to the drive updating instruction, wherein the target level is the highest level to be unloaded in the second kernel module;

And unloading all the sub-kernel modules in the second kernel module from the memory of the operating system in sequence according to the hierarchical order from bottom to top from the lowest hierarchy in the hierarchical relationship until the unloading of the sub-kernel modules of the target hierarchy is completed.

In some embodiments, the related data backup module 705 is further configured to:

determining a sub-kernel module to be unloaded in the second kernel module based on the target level to obtain a module unloading set;

And storing related data corresponding to the module unloading set into a storage unit of the operating system through a sub-kernel module which is not unloaded in the first kernel module or the second kernel module according to the hierarchical sequence from bottom to top from the lowest hierarchy in the hierarchical relationship.

In some embodiments, the callback function clearing module 704 is further configured to:

Starting from the lowest level in the hierarchy relation, sequentially registering private function pointers of callback functions in the sub-kernel modules in the target kernel modules of the sub-kernel modules as null according to the sequence of the levels from bottom to top until the callback functions in the sub-kernel modules of the target level are cleared;

the target kernel module of the sub-kernel module comprises at least one of the first kernel module and a sub-kernel module positioned on the upper layer of the sub-kernel module.

In some embodiments, the kernel module loading module 703 is further configured to sequentially load the new sub-kernel modules in the updated version of the second kernel module into the memory of the operating system in a hierarchical order from top to bottom, starting with the new sub-kernel module in the target hierarchy in the updated version of the second kernel module.

In some embodiments, the related data recovery module 707 is further configured to:

determining a new sub-kernel module to be loaded in the updated version of the second kernel module based on the target level to obtain a module loading set;

and starting from the new sub-kernel module of the target level in the updated version of the second kernel module, sequentially recovering the related data in the storage unit of the operating system to each new sub-kernel module in the module loading set according to the level sequence from top to bottom.

In some embodiments, the callback function registration module 706 is further configured to:

Starting from a new sub-kernel module of the target level in the updated version of the second kernel module, registering callback functions in the new sub-kernel module in the target kernel module of the new sub-kernel module in sequence according to a level sequence from top to bottom;

The target kernel module of the new kernel module comprises at least one of the first kernel module, a new kernel module positioned at the upper layer of the new kernel module and a kernel module positioned at the upper layer of the new kernel module.

In some embodiments, as shown in FIG. 8, the apparatus 700 further includes an export function export module 708 and a kernel module initialization module 709.

An export function export module 708 configured to export a plurality of export functions of the first kernel module to a kernel space of the operating system during loading of the first kernel module, where the plurality of export functions of the first kernel module includes a third export function for registering callback functions with the first kernel module.

The callback function registration module 706 is further configured to call the third export function to register a callback function in the second kernel module in the first kernel module in a process of loading the second kernel module.

A kernel module initializing module 709 for initializing the second kernel module.

In some embodiments, in a case that a first function in the first kernel module is called by a process of a user mode program, the first kernel module calls a first callback function indicated by the first private function pointer in the second kernel module according to a first private function pointer determined by the first function, so as to return an execution result of the first callback function to the process of the user mode program;

In summary, according to the technical scheme provided by the embodiment of the application, the kernel program is split into the first kernel module for receiving the service request and the second kernel module for interacting with the hardware device, and the first kernel module is supported to interact with the hardware device through the second kernel module to process the service request, so that the first kernel module is coupled with the service, and the second kernel module is decoupled from the service. Therefore, the memory of the resident operating system of the first kernel module can be controlled, the receiving of the service request and the state maintenance of the service are realized, and the updating of the kernel program is completed by updating the second kernel module, so that the user is free from feeling, and the kernel program is updated under the condition of not interrupting the service.

It should be noted that, in the apparatus provided in the foregoing embodiment, when implementing the functions thereof, only the division of the foregoing functional modules is used as an example, in practical application, the foregoing functional allocation may be implemented by different functional modules, that is, the internal structure of the device is divided into different functional modules, so as to implement all or part of the functions described above. In addition, the apparatus and the method embodiments provided in the foregoing embodiments belong to the same concept, and specific implementation processes of the apparatus and the method embodiments are detailed in the method embodiments and are not repeated herein.

In some embodiments, there is also provided a computer device comprising an operating system comprising a program management module and a kernel program;

The program management module is used for:

unloading the second kernel module from the memory of the operating system;

In some embodiments, the second kernel module includes at least one callback function for interacting with the hardware device;

the second kernel module is configured to provide the at least one callback function to the first kernel module, and not provide the at least one callback function to other applications other than the first kernel module.

In some embodiments, the second kernel module comprises a plurality of sub-kernel modules having a top-down hierarchical relationship;

At least one of the plurality of sub-kernel modules is used for providing the callback function for the first kernel module;

The ith-level sub-kernel module in the plurality of sub-kernel modules is used for providing a callback function for the ith-1-level sub-kernel module, wherein i is an integer greater than 1;

the callback function is used for interacting with the hardware device.

Reference is made to fig. 9, which is a simplified block diagram of a computer device 900 provided in one possible implementation of the present application. The computer apparatus 900 may be used to implement the kernel program updating method provided in the above-described embodiment.

In general, computer device 900 includes a processor 901 and a memory 902.

Processor 901 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and the like. The processor 901 may be implemented in at least one hardware form of DSP (DIGITAL SIGNAL Processing), FPGA (Field Programmable GATE ARRAY ), PLA (Programmable Logic Array, programmable logic array). The processor 901 may also include a main processor, which is a processor for processing data in a wake-up state, also referred to as a CPU (CentralProcessing Unit ), and a coprocessor, which is a low-power processor for processing data in a standby state. In some embodiments, the processor 901 may integrate a GPU (Graphics Processing Unit, image processor) for rendering and drawing of content required to be displayed by the display screen. In some embodiments, the processor 901 may also include an AI processor for processing computing operations related to machine learning.

The memory 902 may include one or more computer-readable storage media, which may be non-transitory. The memory 902 may also include high-speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In some embodiments, a non-transitory computer readable storage medium in memory 902 is used to store a computer program configured to be executed by one or more processors to implement the above-described kernel program update method.

Those skilled in the art will appreciate that the architecture shown in fig. 9 is not limiting of the computer device 900, and may include more or fewer components than shown, or may combine certain components, or employ a different arrangement of components.

Alternatively, the computer device 900 may be a server, a server cluster, an artificial intelligent computing cluster, a cloud computing cluster, or the like, where the artificial intelligent computing cluster may also be simply referred to as an intelligent computing cluster or a smart computing cluster, which is not limited by the present application.

In some embodiments, a computer readable storage medium is also provided, in which a computer program is stored, which when executed by a processor of a computer device, implements the above-described kernel program updating method.

Alternatively, the computer-readable storage medium may include a ROM (Read-Only Memory), a RAM (Random-Access Memory), an SSD (Solid State disk STATE DRIVES), an optical disk, or the like. The random access memory may include, among other things, reRAM (RESISTANCE RANDOM ACCESS MEMORY, resistive random access memory) and DRAM (Dynamic Random Access Memory ).

In some embodiments, a computer program product is also provided, the computer program product comprising a computer program stored in a computer readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program so that the computer device executes the above-described update method of the kernel program.

It should be understood that references herein to "a plurality" are to two or more. "and/or" describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate that there are three cases of a alone, a and B together, and B alone. The character "/" generally indicates that the context-dependent object is an "or" relationship. In addition, the step numbers described herein are merely exemplary of one possible execution sequence among steps, and in some other embodiments, the steps may be executed out of the order of numbers, such as two differently numbered steps being executed simultaneously, or two differently numbered steps being executed in an order opposite to that shown, which is not limiting.

The foregoing description of the exemplary embodiments of the application is not intended to limit the application to the particular embodiments disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the application.

Claims

1. A method for updating a kernel program, the method comprising:

unloading the second kernel module from the memory of the operating system;

2. The method of claim 1, wherein the second kernel module includes at least one callback function, the call request to call the callback function to interact with the hardware device;

the unloading the second kernel module from the memory of the operating system includes:

And unloading the second kernel module from the memory of the operating system under the condition that the callback function which is being called by the first kernel module does not exist in the second kernel module.

3. The method of claim 2, wherein prior to unloading the second kernel module from the operating system memory, further comprising:

Calling a first export function of the first kernel module, wherein the first export function is used for registering private function pointers corresponding to the at least one callback function in the first kernel module as null;

And for any callback function in the second kernel module, before and after the private function pointer of the callback function is registered as empty, the private function pointer of the callback function is executed by the first kernel module to lock.

4. A method according to any one of claims 1 to 3, wherein prior to said unloading said second kernel module from the memory of said operating system, further comprising:

invoking a second export function of the first kernel module, wherein the second export function is used for storing related data in the second kernel module to a storage unit of the operating system;

The related data are data generated by interaction between the second kernel module and the hardware equipment.

5. A method according to any one of claims 1 to 3, wherein the callback function in the second kernel module is not provided to other applications, and the other applications include at least one of other kernel programs and user mode programs, wherein the user mode programs are applications in user mode when executed.

6. A method according to any one of claims 1 to 3, wherein the first kernel module is further adapted to effect at least one of:

calling export functions of other kernel programs in the operating system;

The plurality of export functions are provided to the second kernel module.

7. A method according to any one of claims 1 to 3, wherein after loading the updated version of the second kernel module into the memory of the operating system, further comprising:

calling a third export function of the first kernel module, wherein the third export function is used for registering a callback function in the updated version of the second kernel module in the first kernel module;

After the updated version of the second kernel module is loaded, the first kernel module is configured to interact with the hardware device by calling a callback function in the updated version of the second kernel module to process the service request.

8. A method according to any one of claims 1 to 3, wherein after loading the updated version of the second kernel module into the memory of the operating system, further comprising:

Calling a fourth export function of the first kernel module, wherein the fourth export function is used for transferring related data in the second kernel module from a storage unit of the operating system to a new storage unit applied by an updated version of the second kernel module;

And after the related data in the second kernel module is restored, the updated version of the second kernel module is used for continuously processing the service request based on the related data.

9. A method according to any one of claims 1 to 3, wherein the second kernel module is divided into a plurality of sub-kernel modules having a hierarchical relationship from top to bottom, in which second kernel module there is at least one sub-kernel module for providing the first kernel module with a callback function, the sub-kernel module of the i-th level for providing the sub-kernel module of the i-1-th level with a callback function, the callback function being for interacting with the hardware device, i being an integer greater than 1;

10. The method of claim 9, wherein prior to unloading the second kernel module from the operating system memory, further comprising:

11. The method of claim 9 or 10, wherein before unloading the second kernel module from the memory of the operating system, further comprising:

12. The method according to any one of claims 9 to 11, wherein loading the updated version of the second kernel module into the memory of the operating system comprises:

Starting from the new sub-kernel module of the target level in the updated version of the second kernel module, loading the new sub-kernel module in the updated version of the second kernel module into the memory of the operating system in sequence according to the level sequence from top to bottom.

13. The method according to any one of claims 9 to 12, wherein after loading the updated version of the second kernel module into the memory of the operating system, further comprising:

14. The method of any one of claims 9 to 13, wherein after loading the updated version of the second kernel module into the memory of the operating system, further comprising:

15. The method of any one of claims 1 to 14, further comprising, prior to receiving the program update instruction:

Exporting a plurality of export functions of the first kernel module to a kernel space of the operating system in the process of loading the first kernel module, wherein the plurality of export functions of the first kernel module comprise a third export function for registering callback functions with the first kernel module;

In the process of loading the second kernel module, calling the third export function to register a callback function in the second kernel module in the first kernel module;

initializing the second kernel module.

16. The method according to claim 15, wherein in the case that a first function in the first kernel module is called by a process of a user mode program, the first kernel module calls a first callback function indicated by the first private function pointer in the second kernel module according to the first private function pointer determined by the first function, so as to return an execution result of the first callback function to the process of the user mode program;

17. A computer device, the computer device comprising an operating system, the operating system comprising a program management module and a kernel program;

The program management module is used for:

unloading the second kernel module from the memory of the operating system;

18. A computer device comprising a processor and a memory, the memory having stored therein a computer program that is loaded and executed by the processor to implement the method of any of claims 1 to 16.

19. A computer readable storage medium having stored therein a computer program that is loaded and executed by a processor to implement the method of any one of claims 1 to 16.

20. A computer program product, characterized in that it comprises a computer program stored in a computer readable storage medium, from which a processor reads and executes the computer program to implement the method according to any of claims 1 to 16.