A linux kernel ko module-based loading method and device

Abstract

The embodiment of the present application provides a loading method and device based on a Linux kernel ko module, the method comprises the following steps: detecting whether a current address is within a dynamic loading address range in a Linux kernel page fault exception processing flow; if the current address is within the dynamic loading address range, performing dynamic loading on the current address through the Linux kernel page fault exception processing flow; when a current standard is switched to another standard, dynamically releasing a code segment dynamically loaded into a physical memory under the current standard through a dynamic releasing interface, so that the problem that, in the related art, the Linux kernel ko module is loaded by loading the ko file into the memory space as a whole, and if the ko version is large, the ko module occupies too much memory can be solved, and the occupied memory of the ko module is reduced through dynamic loading and dynamic releasing.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a method and apparatus for loading a Linux kernel ko module. Background Technology

[0002] Current kernel ko module loading techniques involve relocating all assembly code related to functions and variables within the ko module during Linux kernel startup. Currently, Linux kernel ko modules are loaded entirely into memory. However, if the ko version is large, this can lead to excessive memory consumption by the ko module.

[0003] In related technologies, loading the Linux kernel ko module involves loading the entire ko file into memory. However, if the ko version is large, the ko module may consume too much memory, and no solution has yet been proposed. Summary of the Invention

[0004] This application provides a method and apparatus for loading Linux kernel ko modules, which at least solves the problem in related technologies where loading Linux kernel ko modules involves loading the entire ko file into memory, which can lead to excessive memory usage if the ko version is large.

[0005] According to one embodiment of this application, a method for loading a Linux kernel ko module is provided, comprising:

[0006] In the Linux kernel's page fault handling process, it checks whether the current address is within the dynamically loaded address range;

[0007] If the current address is within the dynamic loading address range, the current address is dynamically loaded through the Linux kernel's page fault handling process;

[0008] When switching from the current system standard to another system standard, the code segments dynamically loaded into physical memory under the current system standard are dynamically released through the dynamic release interface.

[0009] According to another embodiment of this application, a loading device based on a Linux kernel ko module is also provided, comprising:

[0010] The detection module is used to detect whether the current address is within the dynamically loaded address range during the page fault handling process in the Linux kernel.

[0011] The loading module is used to dynamically load the current address through the Linux kernel's page fault handling process if the current address is within the dynamic loading address range.

[0012] The first release module is used to dynamically release the code segments dynamically loaded into physical memory under the current standard through a dynamic release interface when the current standard is switched to another standard.

[0013] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0014] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0015] In this embodiment, the Linux kernel's page fault handling process detects whether the current address is within the dynamically loaded address range. If the current address is within the dynamically loaded address range, the Linux kernel's page fault handling process dynamically loads the current address. When the current system is switched to another system, the code segment dynamically loaded into physical memory under the current system is dynamically released through the dynamic release interface. This solves the problem in related technologies where the Linux kernel ko module loads the entire ko file into memory, which can lead to excessive memory usage if the ko version is large. When a data error or prefetch instruction error page fault occurs before the current address is mapped to a physical address, the Linux kernel's page fault handling process is entered to complete the dynamic loading. By setting a dynamic release interface in the Linux kernel, the dynamically loaded code segment can be dynamically released without the kernel ko module being unloaded. Through dynamic loading and dynamic release, the memory usage of the ko module is reduced. Attached Figure Description

[0016] Figure 1 This is a hardware structure block diagram of a mobile terminal based on the Linux kernel ko module loading method according to an embodiment of this application;

[0017] Figure 2 This is a flowchart of a method for loading a Linux kernel ko module according to an embodiment of this application;

[0018] Figure 3 This is a flowchart illustrating the dynamic loading of the Linux kernel ko module according to this embodiment;

[0019] Figure 4 This is a schematic diagram of the dynamic loading page fault exception process according to this embodiment;

[0020] Figure 5 This is a flowchart illustrating the release process of dynamically loaded Linux kernel ko according to this embodiment;

[0021] Figure 6 This is a block diagram of a loading device based on the Linux kernel ko module according to this embodiment. Detailed Implementation

[0022] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0024] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal based on the Linux kernel ko module loading method according to an embodiment of this application, as shown below. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0025] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the loading method based on the Linux kernel ko module in this embodiment. The processor 102 executes various functional applications and business chain address pool slicing processing by running the computer programs stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0026] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0027] This embodiment provides a method for loading a Linux kernel ko module running on the aforementioned mobile terminal or network architecture. The method is applied to a terminal that accesses the current primary node MN cell and the current secondary node SN cell in the source area via dual connection (DC). Figure 2 This is a flowchart of a method for loading a Linux kernel ko module according to an embodiment of this application, as shown below. Figure 2 As shown, the process includes the following steps:

[0028] Step S202: In the page fault handling process of the Linux kernel, it is checked whether the current address is within the range of dynamically loaded addresses;

[0029] Step S204: If the current address is within the dynamic loading address range, the current address is dynamically loaded through the Linux kernel's page fault handling process;

[0030] Step S206: When switching from the current standard to another standard, dynamically release the code segment dynamically loaded into physical memory under the current standard through the dynamic release interface.

[0031] In this embodiment, step S204 may specifically include:

[0032] S11, a dynamic loading process for dynamically loading the code segment of the kernel ko module is added to the page fault handling process of the Linux kernel.

[0033] S12, in the dynamic loading process, the code segment at the current address is dynamically loaded using a page of a first predetermined size. Further, step S12 can be implemented as follows: If it is determined that the current address causing the exception is within the dynamically loaded link address range, it is determined whether the page table entry corresponding to the current address already exists in the kernel's page table entry; if the determination result is yes, the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process, completing the dynamic loading of the current address; if the determination result is no, if the page corresponding to the current address is currently being mapped, the current dynamic loading process is blocked and waits until other dynamic loading processes of the same page complete mapping and wake up the current process, then the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process. In the table entry, dynamic loading of the current address is completed. If the page corresponding to the current address is not currently being mapped, the page's state is first set to a mapping-in-progress flag. Then, the page offset in the ko code segment is calculated based on the current address. Loading begins with a page of a predetermined size. The read page size data is stored in the allocated temporary memory space, and memory space is simultaneously allocated as the memory management node corresponding to the page to record the temporary storage memory address of the dynamically loaded page and the current address. The current memory management node is added to the linked list. The current address is mapped to the physical memory corresponding to the dynamically loaded page. The kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process, and invalid cache and BTB (Branch Target Buffer) operations are performed simultaneously. If the waiting queue is detected to be empty, dynamic loading of the current address is completed. If the waiting queue is detected to be not empty, the process waiting for mapping completion must be woken up first, and then dynamic loading of the current address is completed.

[0034] The dynamic loading process of ko is implemented in the page fault mechanism of the Linux kernel. When the code segment address in ko is executed, if it is found that it is not mapped to a physical address, the page fault handling process is triggered. Each time it is triggered, a page of code segment is loaded. Code segments that have not been executed are not loaded into memory space.

[0035] In this embodiment, step S206 may specifically include:

[0036] S21, copy the linked list to be released to a temporary linked list;

[0037] S22, traverse and release the temporary linked list. Further, step S22 can be implemented in the following way:

[0038] Remove the memory management node corresponding to the page from the temporary linked list and clear the page's status flag, including clearing the mapped flag bits and resetting the status. Disconnect the mapping relationship between the current address addr in the memory management node and the physical address corresponding to the dynamically loaded page. Clear the TLB (Translation Lookaside Buffer) cache. Release the temporary memory address space of the dynamically loaded page recorded in the memory management node, and release the memory space occupied by the memory management node.

[0039] Without unloading the ko module, the code segment dynamically loaded for the previous standard (LTE / W / GSM) is dynamically released during the switching of standards to save memory space. Here, LTE stands for Long Term Evaluation and GSM stands for Global System for Mobile Communication.

[0040] In an exemplary embodiment, after allocating a fixed starting address to the ko file and completing the relocation processing of all the function and variable assembly code involved in the ko file on the PC (Personal Computer) side, the code segments in the ko file that need to be dynamically loaded are all released during the system startup phase.

[0041] Furthermore, prior to step S202 above, on the PC side, the code segment address range of each application scenario is marked by predefined symbols in the linker script that generates the ko file, and the code segments that need to be dynamically loaded in each application scenario are reordered.

[0042] In another exemplary embodiment, the ko file is fixed as the first one loaded and run, and the ko file is not unloaded. The relocation process of the ko file is completed on the PC side. That is, before the above step S202, the first ko file loaded and run is fixed on the PC side and is not unloaded. In this way, the starting address allocated by the kernel to the ko file is fixed. Therefore, the relocation process of all functions, variable addresses and assembly code involved in the ko file can be completed on the PC. The ko file includes multiple segments such as code segment, data segment, bss segment, and rodata segment.

[0043] This embodiment describes the dynamic loading and unloading of the kernel ko module. During ko loading, the text segment is not loaded into memory. Only when the execution reaches the address of a code segment within ko, if it is found that the current address has not yet been mapped to a physical address, a data error or prefetch instruction error page fault occurs, entering the Linux kernel's page fault handling process to complete the dynamic loading. The Linux kernel's page fault process now supports dynamic loading of the kernel ko module's code segment. Each time a page fault is triggered, a fixed-size page is loaded, saving memory. A dynamic unloading interface is implemented in the Linux kernel to dynamically release the code segment loaded into memory without unloading the kernel ko module. In one application example of this embodiment, the code segment for the previous standard is released during standard (LTE / W / GSM) switching, saving approximately 3MB of memory. This provides excellent memory compression for projects with limited DDR memory configurations, contributing to cost reduction.

[0044] Because the protocol stack is compiled as a single kernel .ko module, the kernel .ko module is quite large. Therefore, dynamic loading and unloading techniques are applied to this kernel .ko module. The specific process is shown in the diagram below. When a multi-mode device starts up, it resides in a specific standard environment. In the business process under the current standard, if the code in the .ko is executed and no physical mapping is found, a page fault is triggered, and the dynamic loading process of the .ko is initiated to complete the mapping. When the standard is switched, the code segments dynamically loaded for the previous standard need to be dynamically released, and then the code segments required for the current standard are dynamically loaded.

[0045] The implementation of application products includes, but is not limited to, protocol stack ko modules. Any kernel ko module can be implemented using this technology to save memory space and reduce equipment costs. Figure 3 This is a flowchart illustrating the dynamic loading of the Linux kernel ko module according to this embodiment, as follows: Figure 3 As shown, it includes:

[0046] Step S301: The LTE multi-mode device is started, including LTE standard camping, W standard camping and GSM standard camping;

[0047] Step S302, select the standard dwell time;

[0048] Step S303: Execute the protocol stack business process;

[0049] Step S304, system switching;

[0050] Step S305: The kernel ko is dynamically released, which releases the previously formatted code segment. Then, step S303 is entered to perform a loop operation.

[0051] S306, determine whether the function in ko has been loaded into memory. If the result is yes, return to step S303; otherwise, proceed to step S307.

[0052] Step S307: Trigger the page fault handling process;

[0053] Step S308: The kernel ko is dynamically loaded, in units of pages;

[0054] Step S309: Complete dynamic loading.

[0055] In this embodiment, the Linux kernel ko is dynamically loaded, which may specifically include:

[0056] 1. PC-side processing of the ko module;

[0057] In existing kernel ko modules, the addresses of functions and variables are determined during loading and runtime. When a ko file is loaded, the Linux kernel performs relocation processing on all assembly code related to functions and variables within that ko. This means that if a ko is loaded / unloaded multiple times, the addresses of functions and variables may differ each time. This solution addresses a protocol stack ko that is always the first ko file loaded and not unloaded. In this scenario, the kernel assigns a fixed starting address to the ko, allowing the relocation of all functions, variables, and assembly code within the ko file to be performed on the PC side (referencing the normal loading process of a Linux kernel ko). This allows subsequent dynamic loading to directly read code segments from the ko file.

[0058] 2. Implementation of the ko linker script;

[0059] The main purpose of the linker script is to reorder the text code segments of dynamically loaded kernel .ko modules and centrally collect and sort them according to the functions executed in the actual application scenario. This aims to collect frequently executed functions in one segment for dynamic loading, effectively improving the utilization of dynamically loaded pages and reducing the number of loads. For text segments of .o files that cannot be dynamically loaded, the EXCLUDE_FILE statement is used to remove .o files that do not need to be linked into other text segments. For example, the ps_2g_func segment below collects all frequently executed functions in the GSM resident format, as shown below:

[0060] SECTIONS {

[0061] / DISCARD / : { (.discard)}

[0062] .text 0: {

[0063] cpko_text_start = .;

[0064] (.ps_2g_func) / / ...

[0065] modem_text_end = .;

[0066] (EXCLUDE_FILE( .o ).text)

[0067] (.stub)

[0068] (.gnu.warning)

[0069] cpko_text_end = .;

[0070] }

[0071] Custom symbols are defined in the linker script to distinguish address ranges for different application scenarios. This allows the kernel to identify which text segment a loaded address belongs to during dynamic loading, enabling timely release based on changes in the application scenario. For example, the variable `cpko_text_start` is the start symbol of the `ko` module's code segment defined in the linker script, and the variable `modem_text_end` is the end symbol of the code segment to be released. These need to be registered in the kernel so that the kernel can use these markers to determine the start and end addresses of dynamically loaded code segments.

[0072] 3. All dynamically loaded .ko code segments are released;

[0073] In the normal process of loading a .ko file using the Linux kernel insomod, the entire .ko file is fully loaded into memory. After the .ko file is loaded, all dynamically loaded code segments need to be released at the .ko file's initialization entry point. At the same time, the handle of the .ko file and the variable markers at the beginning of the text code segments for various application scenarios required by the kernel are obtained. An example of the process is shown below:

[0074] void ko loads the initialization function (void)

[0075] {

[0076] Get the open handle of the .ko file

[0077] The symbolic tags used for kernel registration (defined in the linker script)

[0078] Release code segment range

[0079] return 0;

[0080] }

[0081] 4. KO dynamically loads page fault exception handling process.

[0082] After system startup, when the kernel executes to the address range of dynamically loaded code, this address space has already been completely released at the ko module initialization entry point, so it is not currently mapped to any specific physical address. At this point, the system will generate a data fault and a prefetch instruction fault page fault, respectively calling the do_DataAbort and do_PrefetchAbort functions to handle the page fault. The implementation of dynamic code loading is mainly within this process. Figure 4 This is a schematic diagram of the dynamic loading page fault exception process according to this embodiment, as shown below. Figure 4 As shown, it includes:

[0083] Step S401: Determine whether the virtual address addr that caused the failure is within the dynamically loaded address range based on the input parameters. If the determination result is no, proceed to step S402. If the determination result is yes, proceed to step S403.

[0084] Step S402: Process the kernel according to the solution corresponding to the original failure state.

[0085] Step S403: Determine whether addr has been mapped to the kernel page table entry pointed to by init_mm.pgd. If the result is yes, proceed to step S404; otherwise, proceed to step S405.

[0086] Step S404: Synchronize the kernel page table entry corresponding to addr to the current process page table entry, completing the dynamic loading of this process; (Note: There are many entries in the kernel page table, only the page table entry mapped to the current address is synchronized)

[0087] Step S405: Determine if the page containing addr is currently being mapped. If the result is yes, proceed to step S406; otherwise, proceed to step S407 (Note: Subtract the starting address of the ko code from addr, and then divide by the page size to get the page containing addr).

[0088] Step S406: The current dynamic loading process is blocked and waits until other dynamic loading processes on the same page complete the mapping. Then, the current process is woken up and proceeds to step S404.

[0089] Step S407: Calculate the page offset of addr in the code segment of the ko file. Based on the page offset value, read the ko file with a page of a predetermined size for dynamic loading. Store the read page data in the allocated temporary memory space. Establish a memory management node, record the temporary memory space and addr of the dynamically loaded page, and add the memory management node to the linked list.

[0090] Step S408: Synchronize the kernel page table entry corresponding to addr to the current process page table entry, and perform invalid cache and BTB operations;

[0091] Step S409: Determine if the waiting queue is empty. If the result is no, proceed to step S410. If the result is yes, proceed to step S411.

[0092] Step S410: Trigger the wake-up of other processes mapped to the same page; (Note: This means waking up other waiting processes, not just waiting for them).

[0093] Step S411: The dynamic loading exception handling process ends.

[0094] The load address of the ko module is managed by the kernel page directory table and stored in the main kernel page global directory init_mm.pgd (swapper_pg_dir). Therefore, each time mapping is performed, the kernel's page table base address init_mm.pgd is used directly for mapping according to the original scheme. In the page fault exception handling process, it is necessary to first determine whether the page corresponding to addr has been mapped to the "kernel page table entry". If it has been mapped, it is only necessary to synchronize the "kernel page table entry" of that page to the "page table entry of the current process (current->actinve_mm->pgd)" to complete the address mapping exception process.

[0095] All code segments dynamically loaded into memory are managed by page. Two global variables are defined: an array to manage the mapping status of pages, such as setting the flag indicating that a page is being mapped; and an array of completion values ​​to manage page mapping synchronization. In this way, the mapping of each page is synchronized independently through the completion value. Because the mapping of the same page may be triggered by page fault exceptions by different processes at the same time, synchronization is required. Only one page fault process is allowed to perform virtual address mapping and set the flag indicating that the page is being mapped. Other processes that triggered the page fault exception need to call wait_for_completion(&page_completion[page_index]) to wait for the page mapping to finish before returning if they find that the flag indicating that the page is being mapped is already set. Before returning, the page table entries must be synchronized.

[0096] The function `read_code_file` is an interface used to read relocated .ko module files from the file system. The input parameter is the page offset of the code segment in the .ko file relative to `addr` (reading in pages). The read code segment is temporarily stored in the memory space allocated by `get_zeroed_page(GFP_KERNEL)`, and memory is also allocated as a memory management node to record the storage address and `addr` of dynamically loaded pages.

[0097] This embodiment uses four linked lists to manage memory management nodes, namely GSM / W / LTE / common code segment. When each standard dynamically loads the code segment into memory, it adds the corresponding memory management node to the linked list, which makes it convenient to release the dynamically loaded memory space under other standards when switching standards.

[0098] The code segment has been dynamically loaded into the memory space allocated by get_zeroed_page. At this point, it is necessary to map the virtual address corresponding to addr to the physical memory corresponding to the code segment. This step can be completed by calling ioremap_page(addr & PAGE_MASK,__pa(vir_codebuf),mtype).

[0099] Synchronize the kernel's page table entries to the current process's page table entries, and perform invalid cache and BTB operations to prevent problems caused by cache inconsistency.

[0100] After the mapping process is completed, waitqueue_active(&page_completion[page_index].wait) needs to be called to determine if there is a queue of processes waiting for the page mapping. If there is, complete_all needs to be called to wake up all processes that have completed their tasks.

[0101] The release of dynamically loaded Linux kernel ko in this embodiment specifically includes:

[0102] After system startup, as the test scenario changes, all code will eventually be dynamically loaded into memory. This is the same as the memory occupied by a fully loaded .ko, failing to achieve the goal of saving memory. Therefore, memory release needs to be considered. This solution chooses to release memory during standard switching. This is because during linking, the common code for GSM / W / LTE / modem is linked into separate address ranges. During dynamic loading, it is added to the corresponding linked list based on the linked address range. This allows the release of code for other standards and common codes that have already been loaded during standard switching. At the same time, this memory can also be temporarily released when system memory is low to alleviate system memory pressure. Figure 5 This is a flowchart illustrating the dynamic loading and release process of the Linux kernel ko in this embodiment, as follows: Figure 5 As shown, it includes:

[0103] Step S501: Copy the linked list to be released to a temporary linked list tmp_page_list, and then traverse and release the linked list. This reduces the time spent consuming linked list resources.

[0104] Step S502: Traverse the temporary linked list and delete the memory management nodes recorded in the linked list.

[0105] Step S503: Clear the page mapping status flag recorded in the global variable and reset the completion value. Since the mapping flag was set when a page fault occurred, remember to clear the flag of the page and reset the page_completion value when releasing it.

[0106] Step S504: Disconnect the mapping relationship between the current address addr and the physical address corresponding to the dynamically loaded page recorded in the memory management node, and perform a flush operation on the TLB cache.

[0107] Step S505: Release the temporary storage memory of the dynamically loaded pages recorded by the memory management node, and release the memory management node space at the same time.

[0108] According to another embodiment of this application, a loading device based on the Linux kernel ko module is also provided. Figure 6 This is a block diagram of the loading device based on the Linux kernel ko module according to this embodiment, as follows: Figure 6 As shown, it includes:

[0109] The detection module 62 is used to detect whether the current address is within the range of dynamically loaded addresses in the page fault handling process of the Linux kernel;

[0110] Loading module 64 is used to dynamically load the current address through the Linux kernel's page fault handling process if the current address is within the dynamic loading address range.

[0111] The first release module 66 is used to dynamically release the code segment dynamically loaded into physical memory under the current standard through a dynamic release interface when the current standard is switched to another standard.

[0112] In one exemplary embodiment, the loading module 64 includes:

[0113] A new submodule has been added to enable a dynamic loading process that dynamically loads the code segment of the kernel ko module within the page fault handling process of the Linux kernel.

[0114] A loading submodule is used to dynamically load the code segment at the current address in the dynamic loading process with a page of a first predetermined size.

[0115] In one exemplary embodiment, the loading submodule is further configured to

[0116] If it is determined that the current address causing the exception is within the range of dynamically loaded link addresses, determine whether the page corresponding to the current address has been mapped to the kernel's page table entry;

[0117] If the determination result is yes, the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process, thus completing the dynamic loading of the current address;

[0118] If the result is negative, and the page corresponding to the current address is currently being mapped, the current dynamic loading process is controlled to enter a blocking wait state. After the other dynamic loading processes of the page complete the mapping, the current dynamic loading process is woken up, and the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process to complete the dynamic loading of the current address.

[0119] If the page corresponding to the current address is not currently being mapped, calculate the page offset of the page in the ko code segment based on the current address, and dynamically load the current address based on the page offset.

[0120] In one exemplary embodiment, the loading submodule is further configured to

[0121] Set the page status flag to be in progress for mapping, start loading according to the page offset, store the data read from the page offset in the allocated temporary memory space, and at the same time allocate a second predetermined size of memory as a memory management node for recording the temporary storage memory address of the dynamically loaded page and the current address, and add the memory management node to the linked list;

[0122] The current address is mapped to the physical address corresponding to the temporary memory space, and the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process. At the same time, invalid cache and BTB operations are performed.

[0123] If the waiting queue is detected to be non-empty, the blocked waiting process is awakened to complete the dynamic loading of the current address;

[0124] If the waiting queue is detected to be empty, complete the dynamic loading of the current address.

[0125] In one exemplary embodiment, the first release module 66 includes:

[0126] The copy submodule is used to copy the linked list to be released to a temporary linked list;

[0127] The release submodule is used to traverse and release the temporary linked list.

[0128] In one exemplary embodiment, the release submodule is further configured to

[0129] Remove the memory management node corresponding to the page from the temporary linked list and clear the status flag of the page;

[0130] Disconnect the mapping relationship between the current address and the physical address corresponding to the temporary memory space in the memory management node;

[0131] Perform a clear operation on the TLB cache;

[0132] Release the temporary memory space recorded in the memory management node, and at the same time release the memory occupied by the memory management node.

[0133] In one exemplary embodiment, the apparatus further includes:

[0134] The second release module is used to release all code segments that need to be dynamically loaded in the ko file during the system startup phase.

[0135] In another exemplary embodiment, the device further includes:

[0136] The sorting module is used on the PC side to mark the code segment address range of each application scenario in the linker script that generates the ko file by using predefined symbols, and to reorder the code segments that need to be dynamically loaded in each application scenario.

[0137] In this embodiment, the ko file is always the first one loaded and run, and the ko file is not unloaded. The ko file undergoes relocation processing on the PC side.

[0138] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0139] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0140] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0141] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0142] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0143] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0144] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for loading ko modules based on the Linux kernel, characterized in that, include: In the Linux kernel's page fault handling process, it checks whether the current address is within the dynamically loaded address range; If the current address is within the dynamic loading address range, the current address is dynamically loaded through the Linux kernel's page fault handling process, including: adding a dynamic loading process to the Linux kernel's page fault handling process to dynamically load the code segment of the kernel ko module; and dynamically loading the code segment at the current address with a first predetermined page size in the dynamic loading process. When switching from the current standard to another standard, the code segments dynamically loaded into physical memory under the current standard are dynamically released through the dynamic release interface; The dynamic loading process, which involves dynamically loading the code segment at the current address using a page of a first predetermined size, includes: If it is determined that the current address causing the exception is within the range of dynamically loaded link addresses, determine whether the page corresponding to the current address has been mapped to the kernel's page table entry; If the determination result is yes, the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process, thus completing the dynamic loading of the current address; If the result is negative, and the page corresponding to the current address is currently being mapped, the current dynamic loading process is controlled to enter a blocking wait state. After the other dynamic loading processes of the page complete the mapping, the current dynamic loading process is woken up, and the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process to complete the dynamic loading of the current address. If the page corresponding to the current address is not currently being mapped, calculate the page offset of the page in the ko code segment based on the current address, and dynamically load the current address based on the page offset.

2. The method according to claim 1, characterized in that, Dynamically loading the current address based on the page offset includes: Set the page status flag to be in progress for mapping, start loading according to the page offset, store the data read from the page offset in the allocated temporary memory space, and at the same time allocate a second predetermined size of memory as a memory management node for recording the temporary storage memory address of the dynamically loaded page and the current address, and add the memory management node to the linked list; The current address is mapped to the physical address corresponding to the temporary memory space, and the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process. At the same time, invalid cache and branch target buffer (BTB) operations are performed. If the waiting queue is detected to be non-empty, the blocked waiting process is awakened to complete the dynamic loading of the current address; If the waiting queue is detected to be empty, complete the dynamic loading of the current address.

3. The method according to claim 1, characterized in that, Dynamically releasing code segments dynamically loaded into physical memory through the dynamic release interface includes: Copy the linked list to be released to a temporary linked list; The temporary linked list is traversed and released.

4. The method according to claim 3, characterized in that, Traversing and releasing the temporary linked list includes: Remove the memory management node corresponding to the page from the temporary linked list and clear the status flag of the page; Disconnect the mapping relationship between the current address and the physical address corresponding to the temporary memory space in the memory management node; Clear the address translation backup buffer (TLB) cache. Release the temporary memory space recorded in the memory management node, and at the same time release the memory occupied by the memory management node.

5. The method according to any one of claims 1 to 4, characterized in that, Before checking whether the current address is within the dynamically loaded address range in the Linux kernel's page fault handling process, the method further includes: Release all code segments in the .ko file that need to be dynamically loaded during system startup.

6. The method according to claim 5, characterized in that, Before checking whether the current address is within the dynamically loaded address range in the Linux kernel's page fault handling process, the method further includes: On the PC side, the linker script that generates the .ko file marks the address range of code segments for each application scenario using predefined symbols, and reorders the code segments that need to be dynamically loaded in each application scenario.

7. The method according to claim 6, characterized in that, The .ko file is always the first one loaded and run, and it is not unloaded. The .ko file undergoes relocation processing on the PC side.

8. A loading device based on the Linux kernel ko module, characterized in that, include: The detection module is used to detect whether the current address is within the dynamically loaded address range during the page fault handling process in the Linux kernel. A loading module is configured to dynamically load the current address using the Linux kernel's page fault handling process if the current address is within the dynamically loaded address range. This includes: adding a dynamic loading process to the Linux kernel's page fault handling process to dynamically load the code segment of the kernel's ko module; dynamically loading the code segment at the current address using a page of a first predetermined size in the dynamic loading process; wherein, dynamically loading the code segment at the current address using a page of the first predetermined size in the dynamic loading process includes: if it is determined that the current address causing the exception is within the dynamically loaded link address range, determining whether the page corresponding to the current address has been mapped to a kernel page table entry; if the determination result is yes... In the first case, the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process, completing the dynamic loading of the current address; in the second case, if the page corresponding to the current address is currently being mapped, the current dynamic loading process is controlled to enter a blocking wait state. After the other dynamic loading processes of the page complete the mapping, the current dynamic loading process is woken up, and the kernel page table entry corresponding to the current address is synchronized to the page table entry of the current process, completing the dynamic loading of the current address; if the page corresponding to the current address is not currently being mapped, the page offset of the page in the ko code segment is calculated based on the current address, and the current address is dynamically loaded based on the page offset. The first release module is used to dynamically release the code segments dynamically loaded into physical memory under the current standard through a dynamic release interface when the current standard is switched to another standard.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 7 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 7.

Images