A function calling method and apparatus

Abstract

The application discloses a function calling method and device, which is applied to a system containing at least one driver, each of the drivers is split into at least one independent function module, each of the function modules is registered to a corresponding module manager, the method comprises the following steps: receiving a first request message sent by a first module, the first request message containing the identification of a first function service; searching a target module in a module register according to the identification of the first function service, the module register containing the corresponding relationship between the identification of the first function service and the target module, the target module being used for providing the first function service for the first module, and obtaining the calling interface of the target module; and sending the calling interface of the target module to the first module. According to the method, each function module is independent, and the function code only depends on the function module access interface provided by the module manager, so that the function module can be arbitrarily cut and deployed.

Description

[0001] This application claims priority to the Chinese Patent Application No. 202010895994.3, filed on August 31, 2020, and entitled "A processing method and mobile device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to a system internal interaction method, and more particularly, to a function calling method and device. BACKGROUND

[0003] Modern operating systems usually create two or more address spaces, which can be used to run different programs to ensure system security. Among them, the address space that can directly access the physical address is called "kernel space", which is usually used to run the operating system kernel and driver. In addition, the address space can be called "user space", which can be used to run application programs.

[0004] Device drivers (referred to as drivers) are used to manage devices and implement various functions. Drivers can only run in kernel mode. With the increasing functionality of devices, drivers have become more and more complex. In fact, not all products need all device functions, some of which are needed and some of which are not needed. The driver corresponding to the function not needed can be deleted, which is usually referred to as driver pruning.

[0005] With the complexity of peripherals and protocols used to operate peripherals, drivers have become more and more complex. If each driver is written as a kernel module, the operating system contains multiple kernel modules, each of which can provide one or more interfaces to the user space through a specific method, such as Figure 1 "InterfaceFunX" in the above, which is completed by calling a series of internal methods, such as Figure 1 "InnerFuncX" in the above. When there is interaction between two or more kernel modules, it will cause mutual coupling between codes, such as when driver A1 needs to call driver A2, it will call the interface "InterfaceFunc" in driver A2, so the interface "InterfaceFunc" exists for driver A1. Dependence. For example, interface "InterfaceFunA" can directly call method "InnerFunc1" and method "InnerFunc2", and interface A and methods 1 and 2 also have a mutual coupling relationship.

[0006] When the driver is pruned, only those interfaces and methods that are not dependent on other interfaces can be pruned. For those interfaces and methods that have dependencies, if they are pruned, errors will occur during compilation and linking, causing abnormality of the unpruned drivers, so in the increasingly complex drivers, problems of difficult building, difficult pruning, difficult maintenance, and difficult deployment will occur. SUMMARY

[0007] The present application provides a function calling method and device to overcome the technical problems of difficult building, difficult pruning, difficult maintenance, and difficult deployment caused by the complexity of the driver. Specifically, the present application discloses the following technical solutions:

[0008] In a first aspect, the present application provides a function calling method, which is applied to a system comprising at least one driver, and each driver is split into at least one independent function module, each function module is registered to a corresponding module manager, and the method comprises:

[0009] The module manager receives a first request message sent by a first module, the first request message comprising an identifier of a first function service; finds a target module according to the identifier of the first function service in a module registration table, the module registration table comprising a corresponding relationship between the identifier of the first function service and the target module, the target module being used to provide the first function service for the first module; obtains a calling interface of the target module according to the target module; and sends the calling interface of the target module to the first module.

[0010] In this method, the driver modules of the system are split into smaller function modules in advance, the split function modules are independent of each other and are not coupled with each other, and then the communication is performed through synchronous messages, asynchronous messages, and one-way messages, so that each function module accesses or obtains the related functions of other function modules through the calling interface.

[0011] In addition, since each split function module is independent of each other and the function code only depends on the function module access interface provided by the module manager, the function module can be pruned arbitrarily. Even if the other function modules accessed by a function module are pruned, a response can be made after the request for the target function module manager fails, and no abnormality will occur during compilation, linking, and running, overcoming the problems of difficult building, difficult pruning, difficult maintenance, and difficult deployment.

[0012] With reference to the first aspect, in a possible implementation form of the first aspect, the target module is found in the module registry according to the identification of the first function service, including: the function module capable of providing the first function service is found in the module registry according to the identification of the first function service, and the function module capable of providing the first function service is determined as the target module.

[0013] With reference to the first aspect, in another possible implementation form of the first aspect, the calling interface of the target module is obtained, including: the target module manager in which the target module is located is determined; the calling mode is determined according to the location of the target module manager and the location of the first module manager; the calling interface of the target module is determined according to the calling mode and the correspondence between the calling mode and the calling interface.

[0014] The calling mode includes: same address space calling and different address space calling.

[0015] With reference to the first aspect, in still another possible implementation form of the first aspect, the module manager corresponding to the first module is the first module manager, and the location of the first module manager is in the kernel space or the user space; when the location of the target module manager and the location of the first module manager are in the same address space, the calling mode is same address space calling; the calling interface of the target module is determined, including: when the calling mode is same address space calling, the calling interface of the target module includes: a method of directly accessing the target module address and the target module address.

[0016] With reference to the first aspect, in still another possible implementation form of the first aspect, when the location of the target module manager and the location of the first module manager are in different address spaces, the calling mode is user space calling kernel space or kernel space calling user space; the calling interface of the target module is determined, including:

[0017] When the calling mode is user space calling kernel space, the calling interface of the target module includes: a method of initiating calling of the kernel space interface using an operating system, and interface data required for calling the kernel space interface.

[0018] When the calling mode is kernel space calling user space, the calling interface of the target module includes: a method of initiating calling of the user space interface using an operating system, and interface data required for calling the user space interface.

[0019] With reference to the first aspect, in a possible implementation form of the first aspect, when the first module manager is located in a first user space and the target module manager is located in a second user space, the calling mode is cross-user address space calling, and the determining of the calling interface of the target module comprises: when the calling mode is cross-user address space calling, the calling interface of the target module comprises: using a method between operating system processes to initiate a call to the second user space interface, and interface data required for calling the second user space interface.

[0020] With reference to the first aspect, in a possible implementation form of the first aspect, before the obtaining of the calling interface of the target module, the method further comprises: determining whether the first module has been registered in the first module manager; if not, and the first module manager is a module manager in a kernel space, registering and saving relevant information of the first module, the relevant information of the first module comprising: an identifier of the first module, all functions contained in the first module, and a function identifier corresponding to each of the functions.

[0021] In the implementation form, the first module registers the corresponding identifier, the contained functions and the function identifiers and the like information in the module manager, thereby preparing for the subsequent calling of the functions of the first module, and the module manager can realize the centralized management of all the functions through the registration.

[0022] With reference to the first aspect, in a possible implementation form of the first aspect, the method further comprises: if the first module manager is a module manager in a user space, registering the relevant information of the first module in the module manager in the kernel space; and when receiving an indication sent by the module manager in the kernel space, determining that the first module is successfully registered in the module manager in the kernel space. In the implementation form, the relevant functions of the function module are reported to the module manager in the kernel space, thereby realizing the calling of the module functions between the kernel space and the user space.

[0023] In a second aspect, the application further provides a module manager, which is generated when at least one driver is split into at least one independent function module by a system, and the module manager registers relevant information of at least one function module, the module manager comprising:

[0024] A receiving unit is configured to receive a first request message sent by a first module, the first request message including an identifier of a first functional service; a processing unit is configured to search for a target module in a module registry based on the identifier of the first functional service, and to obtain the calling interface of the target module, the module registry including the correspondence between the identifier of the first functional service and the target module, the target module being used to provide the first functional service to the first module; and a sending unit is configured to send the calling interface of the target module to the first module.

[0025] In conjunction with the second aspect, in one possible implementation of the second aspect, the processing unit is further configured to search for a functional module capable of providing the first functional service in the module registry based on the identifier of the first functional service, and determine the functional module capable of providing the first functional service as the target module.

[0026] In conjunction with the second aspect, in another possible implementation of the second aspect, the processing unit is further configured to: determine the target module manager where the target module is located; determine the calling mode based on the location of the target module manager and the location of the first module manager; and determine the calling interface of the target module based on the calling mode and the correspondence between the calling mode and the calling interface.

[0027] In conjunction with the second aspect, in another possible implementation of the second aspect, the module manager corresponding to the first module is a first module manager, and the location of the first module manager is in kernel space or user space; when the location of the target module manager and the location of the first module manager are in the same address space, the calling mode is a same address space call; the processing unit is further configured to determine, when the calling mode is a same address space call, that the calling interface of the target module includes a method for directly accessing the address of the target module and the address of the target module.

[0028] In conjunction with the second aspect, in another possible implementation of the second aspect, when the location of the target module manager is in a different address space from the location of the first module manager, the calling mode is user space calling kernel space, or kernel space calling user space; the processing unit is further configured to, when the calling mode is user space calling kernel space, determine the calling interface of the target module by: initiating a call to the kernel space interface using a method provided by the operating system, and the interface data required to call the kernel space interface; when the calling mode is kernel space calling user space, determine the calling interface of the target module by: initiating a call to the user space interface using a method provided by the operating system, and the interface data required to call the user space interface.

[0029] In conjunction with the second aspect, in another possible implementation of the second aspect, when the location of the first module manager is in the first user space and the location of the target module manager is in the second user space, the invocation mode is an address space invocation between users;

[0030] The processing unit is further configured to determine the calling interface of the target module when the calling mode is an address space call between users, including: initiating a call to the second user space interface using an inter-process method of the operating system, and the interface data required to call the second user space interface.

[0031] In conjunction with the second aspect, in another possible implementation of the second aspect, the processing unit is further configured to determine whether the first module has been registered in the first module manager before obtaining the calling interface of the target module; if not, and the first module manager is a kernel space module manager, then register and save the relevant information of the first module, the relevant information of the first module including: the identifier of the first module, all functions contained in the first module, and the function identifier corresponding to each function.

[0032] In conjunction with the second aspect, in another possible implementation of the second aspect, the processing unit is further configured to register the relevant information of the first module to the module manager of the kernel module if the first module manager is a user space module manager; and to determine that the first module has been successfully registered in the module manager of the kernel space when the receiving unit receives an instruction sent by the module manager of the kernel space.

[0033] Thirdly, this application also provides a capability invocation method, including at least one functional module and at least one module manager, wherein the at least one functional module is generated by splitting at least one driver program of the system, and the module manager registers relevant information of the at least one functional module; the method includes:

[0034] The first module sends a first request message to the first module manager, the first request message including the identifier of the first functional service; the first module manager receives the first request message, searches for the target module in the module registry according to the identifier of the first functional service, obtains the calling interface of the target module, and sends the calling interface of the target module to the first module, the module registry including the correspondence between the identifier of the first functional service and the target module; the first module receives the calling interface of the target module and uses the calling interface of the target module to request the first functional service from the target module.

[0035] Fourthly, this application also provides a driver splitting method, which can split a driver in an operating system into at least one independent functional module. Specifically, the method includes: obtaining an interface set contained in a first kernel module, wherein the interface set contained in the first kernel module includes at least one interface; obtaining the methods that each interface in the interface set can call and the calling relationships between the methods; generating a first hierarchical structure based on the methods that each interface can call and the calling relationships; determining whether there are duplicate method functions in the first hierarchical structure, and if so, deleting the duplicate method functions to obtain a second hierarchical structure.

[0036] Optionally, the first hierarchical structure may also be called a "call tree".

[0037] In conjunction with the fourth aspect, in one possible implementation of the fourth aspect, determining whether there are duplicate method functions in the first hierarchical structure includes: determining whether there are calls to the same method function in two or more interfaces of the first hierarchical structure.

[0038] Specifically, determining whether the method functions of each layer in the first functional module have the same method functions in the functional modules of other interfaces includes:

[0039] First, determine the average number of times (n) each method function in the first functional module is called during the business call process. If two or more method functions are the same, select the one with the larger average number of times (n) is called as the retained method function, and delete the method function in the functional module with the smaller value of n.

[0040] Secondly, if the average number of times n is called in two or more method functions is the same, then the calling status of each method function in each functional module is determined. The calling status includes mandatory calls and conditional calls; among them, mandatory calls have higher priority than conditional calls.

[0041] If only one of two or more method functions is in a state of guaranteed invocation, while the rest are in a state of conditional invocation, then the method function corresponding to the guaranteed invocation state is determined to be the method function to be retained, and the other method functions in the state of conditional invocation need to be deleted.

[0042] Additionally, it includes: if two or more method functions have the same state, such as both being mandatory or conditional calls, then the decision on whether to retain them is based on the priority of the business function to which the called method function belongs; specifically, the business function with higher priority is retained, and the method function with lower priority is deleted.

[0043] Optionally, the split driver can be located in user space or kernel space.

[0044] Fifthly, this application also provides a method for deploying a functional module, used to move a functional module from one space to another, such as moving a kernel module to user space. Specifically, the method includes:

[0045] Deploy a first process in user space, which can be a user-mode process or a user-space process; deploy a first functional module from the kernel module into the functional module corresponding to the first process, and add a new module manager to the functional module of the first process to manage and call all or part of the functions of the first functional module; delete the first functional module in the kernel space, as well as all functions in the target module manager of the kernel space that call the first functional module.

[0046] Optionally, in any of the following scenarios, the functional module relocation shall be performed according to the method described in aspect six above. Specifically, the scenarios include:

[0047] When functional module C in the second user space wants to call function A1 or function A2 in the first kernel module; or...

[0048] When functional module C in the second user space wants to call functional module B1 in the first user space; or...

[0049] When functional module A in the first kernel module wants to call functional module B1 in the first user space; or...

[0050] When functional module A in the first kernel module wants to call functional C1 in the second user space.

[0051] In this respect, when a functional module needs to be moved from user space to kernel space, or vice versa, because the modules are split and deployed, they no longer have dependencies on each other. They only depend on the calling interfaces provided by the respective module managers and use the same parameters. Therefore, the function calls between modules are completely unaware of this change. Using the module manager for each functional module, the deployment location of the functional module can be flexibly migrated without modifying the module's code.

[0052] In a sixth aspect, this application also provides a module management device, which includes a processor and a memory, wherein the processor is coupled to the memory, the memory is used to store computer program instructions; the processor is used to execute the instructions stored in the memory so that the module management device performs the methods in the first aspect and various implementations thereof.

[0053] Specifically, the processor is configured to receive a first request message sent by a first module, the first request message including an identifier of a first functional service; the processor is further configured to search for a target module in a module registry based on the identifier of the first functional service, obtain a calling interface of the target module based on the target module; and send the calling interface of the target module to the first module; wherein, the module registry includes a correspondence between the identifier of the first functional service and the target module, and the target module is configured to provide the first functional service to the first module.

[0054] In addition, the module management device also includes an interface circuit, which is used to enable communication between the device and other external modules.

[0055] Optionally, the processor and memory can be integrated into a single processing chip or chip circuit.

[0056] In a seventh aspect, this application also provides a computer-readable storage medium storing instructions that, when executed on a computer or processor, can be used to perform the methods described in the first and third aspects above.

[0057] In addition, this application also provides a computer program product including computer instructions that, when executed by a computer or processor, can implement the methods in the first aspect and various implementations of the first aspect.

[0058] It should be noted that the beneficial effects of the various implementation methods of the second to seventh aspects mentioned above are the same as those of the first aspect and its various implementation methods. For details, please refer to the description of the beneficial effects in the first aspect and its various implementation methods, which will not be repeated here. Attached Figure Description

[0059] Figure 1 A schematic diagram of the kernel space structure provided in this application;

[0060] Figure 2 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application;

[0061] Figure 3 This is a schematic diagram illustrating the calling relationship between interfaces and method functions in kernel space, provided as an embodiment of this application.

[0062] Figure 4 This application provides a schematic diagram of a structure divided into multiple functional modules.

[0063] Figure 5 A signaling flowchart of a function invocation method provided in an embodiment of this application;

[0064] Figure 6 A schematic diagram illustrating function calls between multiple functional modules provided in an embodiment of this application;

[0065] Figure 7 A flowchart illustrating the registration of a functional module is provided in an embodiment of this application;

[0066] Figure 8 A flowchart illustrating how to obtain a calling interface is provided in an embodiment of this application;

[0067] Figure 9 A flowchart illustrating a request function service and obtaining a call interface is provided in this application embodiment;

[0068] Figure 10 A schematic diagram of a hierarchical structure provided in an embodiment of this application;

[0069] Figure 11 A schematic diagram of another hierarchical structure provided in an embodiment of this application;

[0070] Figure 12 This is a schematic diagram of a functional module movement provided in an embodiment of this application;

[0071] Figure 13 This application provides a schematic diagram of the structure of a module manager according to an embodiment of the present application.

[0072] Figure 14 This is a schematic diagram of a terminal device operating system provided in an embodiment of this application. Detailed Implementation

[0073] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Before describing the technical solutions in the embodiments of this application, the application scenarios of the embodiments of this application will first be described with reference to the accompanying drawings.

[0074] The technical solution of this application can be applied to a terminal device, and the technical solution involves the trimming and deployment of drivers in the operating system of the terminal device.

[0075] Figure 2 A schematic diagram of a terminal device is shown. The terminal device may include a processor 110 and a memory 120, and may also include: a sensor module 130, an audio module 140, a mobile communication module 150, a wireless communication module 160, an antenna 1, an antenna 2, a display screen 170, a camera 180, a USB interface 190, a power management module 191, etc.

[0076] The sensor module 130 may include a pressure sensor 130A, a gyroscope sensor 130B, and a touch sensor 130C. In addition, the sensor module 130 may also include an accelerometer, a temperature sensor, an ambient light sensor, etc.

[0077] The audio module 140 includes a speaker 140A, a receiver 140B, and a microphone 140C. It also includes a headphone jack, etc.

[0078] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the terminal device. In other embodiments of this application, more or fewer components may be included than illustrated, or some components may be combined, some components may be split, or different component arrangements may be made. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0079] Processor 110 may include one or more processing modules, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). Different processing modules may be independent devices or integrated into one or more processors.

[0080] The processor 110 can be the nerve center and command center of the terminal device. The processor 110 can generate operation control signals according to the instruction opcode and timing signals to complete the operation of reading and executing instructions.

[0081] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can directly retrieve it from the memory 120, avoiding repeated access, reducing the waiting time of the processor 110, and improving the efficiency of the system.

[0082] Optionally, the processor 110 is a processing chip or processing circuit.

[0083] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an Inter-Integrated Circuit (I2C) interface, an Inter-Integrated Circuitsound (I2S) interface, a Pulse Code Modulation (PCM) interface, a Universal Asynchronous Receiver / Transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI) interface, a General-Purpose Input / Output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and / or a Universal Serial Bus (USB) interface, etc.

[0084] The USB 190 interface is a USB standard compliant interface, which can be a Mini USB interface, MicroUSB interface, USB Type-C interface, etc. The USB 190 interface can be used to connect external devices, such as chargers.

[0085] A power management module 191 is used to connect the battery and the processor 110. The power management module 191 supplies power to the processor 110, memory 120, display screen 170, camera 180, and wireless communication module 160, etc. In some embodiments, the battery may be housed within the power management module 191. Optionally, a charging management module may also be included, which receives charging input from a charger and, while charging the battery, can also supply power to the terminal device via the power management module 191.

[0086] The wireless communication function of electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the terminal device can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0087] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0088] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through audio devices (not limited to speaker 140A, receiver 140B, etc.) or displays images or videos through the display screen 170. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and housed within the same device as the mobile communication module 150 or other functional modules.

[0089] The wireless communication module 160 can provide solutions for wireless communication technologies such as Wireless Local Area Networks (WLANs) (e.g., Wireless Fidelity (Wi-Fi) networks), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), and Infrared (IR). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 can also receive signals to be transmitted from the processor 110, perform frequency modulation and amplification, and then convert them into electromagnetic waves for transmission via the antenna 2.

[0090] In some embodiments, antenna 1 of the terminal device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the terminal device to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), and BeiDou Navigation Satellite System (BDS), etc.

[0091] The terminal device can implement display functions through a GPU, a display screen 170, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 170 and the application processor. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0092] The display screen 170 is used to display application interfaces, windows, controls, etc. The display screen 170 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the terminal device may include at least one display screen 170.

[0093] A camera 180 is used to capture and acquire images. In some embodiments, the terminal device may include one or N cameras 180, where N > 1 and is a positive integer.

[0094] The memory 120 can be used to store computer executable program code, including instructions. The internal memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system, such as kernel space and user space. The data storage area may store data created during the use of the terminal device.

[0095] Furthermore, memory 120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and interface processing of the terminal device by running instructions stored in memory 120.

[0096] Additionally, it may include an external storage card, such as a Micro SD card, for expanding the storage capacity of the terminal device. The external storage card can be connected to the processor 110 via an external memory interface to perform data storage functions. For example, music, video, and other files can be stored on the external storage card.

[0097] In sensor module 130, pressure sensor 130A is used to sense pressure signals and convert them into electrical signals. Gyroscope sensor 130B can be used to acquire the motion posture of the terminal device. Touch sensor 130C, also known as a "touch device," can be placed on display screen 170, and the touch sensor 130C and display screen 170 together form a touch screen. Touch sensor 130C is used to detect swipe gesture touch operations applied to or near it.

[0098] In this embodiment, the terminal device can be a portable device, such as a smart terminal, mobile phone, laptop computer, tablet computer, personal computer (PC), personal digital assistant (PDA), foldable terminal, wearable device with wireless communication function (e.g., smartwatch or bracelet), user device (UE), smart home device (e.g., television), in-vehicle computer, game console, and augmented reality (AR) / virtual reality (VR) device, etc. The embodiments of this application do not limit the specific device form of the terminal device. Furthermore, the various terminal devices mentioned above include, but are not limited to, those running Apple (iOS), Android, Microsoft, or other operating systems.

[0099] In any of the operating systems mentioned above, programs running in the kernel address space are defined as running in kernel mode, or kernel space. Programs running in the user address space are defined as running in user mode, or user space. Kernel mode or kernel space can access devices directly or through physical addresses. Programs in user mode or user space cannot directly access devices; therefore, they can only access devices by switching to kernel mode via system calls and then calling the interfaces provided by the device driver. If an exception occurs in a program running in user mode, it may cause that user process to crash.

[0100] This example uses a Linux system. In Linux, each driver can be considered as one or more kernel modules, where each kernel module is written by the driver program and can be compiled into a binary file. These kernel module binaries can be directly linked into the operating system kernel or linked into independent kernel module files (such as .ko files). If the driver is directly linked into the operating system kernel, it will be loaded directly with the operating system. In this case, the .ko file can also be loaded by the operating system at runtime. However, regardless of the loading method, kernel modules can only be deployed in kernel space, not user space.

[0101] In addition, each kernel module can provide one or more interfaces to user space through specific methods (such as device nodes, netlinks, etc.), and these interfaces perform their functions by calling a series of internal methods.

[0102] When there is interaction between two kernel modules, the callee method is usually declared directly in the code and then called directly. For example... Figure 3 As shown, a kernel space includes two kernel modules, namely kernel module 1 and kernel module 2. When kernel module 1 wants to call an interface of kernel module 2, it usually declares it in the code.

[0103] The statement is as follows:

[0104] extern void InterfaceFunc(...) / / An interface named "InterfaceFunc" is written elsewhere;

[0105] call InterfaceFunc(...) / / When the program reaches this point, it calls the interface "InterfaceFunc" written elsewhere.

[0106] Here, InterfaceFunc represents the interface provided by the kernel module to the kernel space; InnerFunc represents the method called using the above interface. The arrow "→" indicates the calling relationship. The method or interface pointed to by the tail of the arrow needs to call the method or interface pointed to by the arrow. For example, interface InterfaceFuncA calls interface InterfaceFuncB, and interface InterfaceFuncA calls method InnerFunc1 or method InnerFunc2.

[0107] The arrows used above represent the relationship between interfaces and methods, directly coupling interfaces to each other, interfaces to methods, or methods to methods. This is useful when it's necessary to remove certain interfaces or methods, such as... Figure 3 The content filled in represents the content that needs to be pruned, including interfaces InterfaceFuncB and InterfaceFuncC, and method InnerFunc3. Direct pruning will cause errors in the coupled InterfaceFuncA and InnerFunc2 because they cannot find the interface / method to be called. In addition, different interfaces and methods that have dependencies before pruning will also have certain difficulties in deployment, such as difficulty in building, pruning, maintenance, and deployment.

[0108] To improve trimming efficiency and reduce deployment difficulty, this embodiment splits each driver in the operating system into at least one independent functional module. For example, kernel module 1 is split into functional module A and functional module B, and kernel module 2 is split into functional module C. Figure 4 As shown, each of the split functional modules provides one or more functional interfaces, and a module manager is used to manage these modules, enabling methods or functions within each module to be called by other modules. For example, when functional module A needs to call the function of functional module B, the following steps are executed: Figure 5 As shown, the method includes:

[0109] 101: The first module sends a first request message to the first module manager, and correspondingly, the first module manager receives the first request message sent by the first module. Here, the first module manager is the module manager where the first module is located, and it is used to manage the request messages of the first module and the function calls to the first module.

[0110] The first request message is used to request the provision of a first functional service, and the first request message includes an identifier (ID) of the first functional service. See also Figure 4 The split kernel space includes functional module A, functional module B, and functional module C. The first module can be any one of functional modules A, B, or C, and the first module manager is the module manager of the kernel space. When the first module is functional module A, and functional module A requests the first module manager to provide function B1, the first request message carries the identifier ID of functional module B. Similarly, when the first module is functional module B and requests function C1, the first request message carries the identifier ID of functional module C.

[0111] 102: After receiving the first request message, the first module manager searches for the target module in the module registry according to the identifier ID of the first function service. The target module is able to provide the first function service to the first module.

[0112] The module registry is pre-acquired and stored locally by the first module manager. This registry includes at least one functional service identifier ID and module number, as well as the correspondence between the functional services provided by each module. See Table 1, which illustrates the correspondence between a functional service identifier ID, module number, and module function.

[0113] Table 1. Module Registry

[0114] Identification ID of the functional service Module number Module function Identification ID 1 Functional module A Function A1, Function A2 Identification ID 2 Functional module B Function B1 Identification ID 3 Functional module C Function C1 …… …… ……

[0115] In one example, if the first module requests to provide function B1 of function module B, the first module manager searches for the function module that can provide function B1 in the module registry shown in Table 1 based on the function service identifier ID2 carried in the first request message. In this example, only function module B has function B1, so the target module is determined to be function module B.

[0116] Optionally, if the identifier of the functional service carried in the first request message is ID1, then the target module is determined to be functional module A; if the identifier of the functional service carried is ID3, then the target module is determined to be functional module C.

[0117] The process of generating this module registry is described in subsequent embodiments. It should be understood that the module registry may include other, more or fewer, contents, and this embodiment does not limit this.

[0118] 103: The first module manager obtains the calling interface of the target module.

[0119] The target module's calling interface is the interface through which the target module provides a first functional service to the first module. This calling interface can be an assembly interface; furthermore, the assembly interface can be assembled when requesting a module, or it can be assembled during module registration or synchronization. This embodiment does not impose any limitations on this.

[0120] Optionally, before step 103, the method further includes: the first module manager first performs a permission check on the target module; if the permission check is successful, step 103 is executed to obtain the calling interface of the target module. If the permission check of the target device is unsuccessful, the first request message initiated by the first module fails, and the process ends. This embodiment does not limit the specific process of permission checking.

[0121] Step 103 specifically includes:

[0122] 103-1: The first module manager determines the target module manager where the target module resides. Specifically, the first module manager determines the location of the target module based on its access address, and then searches for which module manager it belongs to based on its location. The module manager found is the target module manager.

[0123] 103-2: The first module manager determines the calling interface of the target module based on the location of the target module manager and the location of the first module manager.

[0124] The location of the target module manager can be known in advance. For example, the first module manager can obtain the location information (such as access addresses) of all module managers in the operating system in advance; or, the address of the target module manager can be obtained during data synchronization. The location of the first module manager is known locally.

[0125] The first module manager first determines the calling mode based on the positions of the target module manager and the first module manager, and then determines the calling interface of the target module based on the correspondence between the calling mode and the calling interface.

[0126] 103-3: The first module manager obtains the calling interface.

[0127] In step 103-2, the location of the target module manager and the location of the first module manager have the following two relationships:

[0128] 1. The target module manager and the first module manager reside in the same space, such as both in user space or kernel space;

[0129] 2. The target module manager and the first module manager reside in different spaces, such as one in user space and the other in kernel space.

[0130] Furthermore, in case "1", the following scenarios are specifically included: the target module manager and the first module manager are both located in the same kernel space, such as kernel space 1; or, the target module manager and the first module manager are both located in the same user space, such as user space 1; or, the target module manager and the first module manager belong to two different user spaces, such as the first module manager being located in user space 1 and the target module manager being located in user space 2. In case "2", the following scenarios are specifically included: the target module manager and the first module manager are located in different spaces, such as the first module manager being located in user space 1 and the target module manager being located in kernel space 1; or conversely, the target module manager being located in user space 1 and the first module manager being located in kernel space 1.

[0131] Specifically, please refer to Table 2 for the various possible scenarios mentioned above.

[0132] Table 2. Module Manager Deployment Location Relationship Table

[0133]

[0134] Relation "1" corresponds to two calling modes: calls within the same address space and calls between different user address spaces. Relation "2" corresponds to two other calling modes: user space calling kernel space and kernel space calling user space.

[0135] After determining the current calling mode based on the positional relationships shown in Table 2, the first module manager then determines the calling interface of the target device based on the correspondence between the calling mode and the calling interface. The correspondence between the calling mode and the calling interface is shown in Table 3.

[0136] Table 3. Correspondence between Invocation Mode and Invocation Receiver

[0137]

[0138] As shown in Table 3, the calling interface includes the calling method and the interface data required to use that calling method. Specifically, under the same address space calling mode, the target module's calling method directly accesses the other party's (target module's) address, and the interface data is the other party's address. For example, in... Figure 4 In the first module, functional module A, and the target module, functional module B, the calling module is determined to be a "call within the same address space" based on the deployment locations of functional module A and functional module B. According to the pre-defined correspondence in Table 3, the calling interface of the target module includes direct access to functional module B and the address of functional module B.

[0139] In another example, when the location of the target module manager is in a different address space than the location of the first module manager, the calling pattern is user space calling kernel space, or kernel space calling user space; obtaining the calling interface of the target module in step 103-3 above includes:

[0140] When the calling mode is user space calling kernel space, the calling interface of the target module includes: initiating a call to the kernel space interface using methods provided by the operating system, and the interface data required to call the kernel space interface;

[0141] When the calling mode is kernel space calling user space, the calling interface of the target module includes: initiating a call to the user space interface using methods provided by the operating system, and the interface data required to call the user space interface.

[0142] For example, Figure 6As shown, when the first module is functional module B and the target module is functional module A in the kernel space, the calling mode is determined to be "user space calling kernel space" or "user mode calling kernel mode" based on the location of the first module manager in user space 1 and the location of the target module manager in kernel space. Then, the calling interface of the target module is determined according to the preset correspondence, including: using the operating system's IOCTL, Netlink and other means to initiate a system call, thereby calling the kernel mode interface; the calling method needs to use the data required by IOCTL, Netlink and other means, such as file handles, method identification IDs, etc.

[0143] IOCTL (input / output control) is a function in the device driver that manages the device's I / O channels. Netlink is an inter-process communication (IPC) mechanism used for communication between the kernel and user space, and also for inter-process communication.

[0144] In another example, when the first module manager is located in the first user space and the target module manager is located in the second user space, the invocation mode is "inter-user address space invocation". In this case, determining the invocation interface of the target module includes: when the invocation mode is inter-user address space invocation, the invocation interface of the target module includes initiating a call to the second user space interface using operating system inter-process methods, and providing the interface data required to call the second user space interface. The operating system inter-process methods include, but are not limited to, methods based on sockets, pipes, and IPC.

[0145] For example, if user space 1 calls a function of user space 2, the corresponding target module's call interface includes: implementing capability calls based on communication mechanisms such as socket, pipe, and IPC. The required interface data includes information such as socket ID, pipe name, and IPC address.

[0146] It should be noted that this embodiment only illustrates the calling methods under the different calling modes and the interface data required for the calling methods, including but not limited to the calling methods and interface data shown above. Other calling methods and interface data can also be used, as long as they can call the capabilities of the target module and provide the first functional service for the requested first module. This embodiment does not provide examples of each of these.

[0147] In addition, another implementation of step 103 above is that the first module manager directly obtains the calling interface of the target module. The calling interface can be assembled during the module registration phase. The specific process is described in the registration process. At the same time, each functional module needs to be synchronized when it is registered to the module manager.

[0148] See Figure 5 The above methods also include:

[0149] 104: The first module manager sends the calling interface of the target module to the first module. Correspondingly, the first module receives the calling interface of the target module sent by the first manager.

[0150] 105: The first module uses the target module's calling interface to request the first function service from the target module.

[0151] 106: After receiving the request from the first module, the target module starts the process related to the first function service and outputs the first service response.

[0152] 107: The target module sends the first service response to the first module.

[0153] In this embodiment, the first module obtains the calling interface of the target module fed back by the module manager, and uses the calling interface to complete the function call of the target module.

[0154] This method pre-decomposes the system's driver module into smaller granular functional modules. These modules are independent of each other and are not coupled. They then communicate through synchronous messages, asynchronous messages, and one-way messages, allowing each functional module to access or obtain relevant functions from other functional modules by calling interfaces.

[0155] Furthermore, since the various functional modules are independent of each other, and the functional code only depends on the functional module access interface provided by the module manager, the functional modules can be arbitrarily trimmed. Even if other functional modules that a functional module needs to access are trimmed, a response can still be made after the request to the target functional module manager fails, without causing compilation, linking, or runtime exceptions, thus overcoming the problems of difficult driver construction, trimming, and maintenance.

[0156] The following describes the process of generating the "module registry" in step 102 above. This embodiment uses the registration of the functions of the first module to the first module manager as an example for illustration. Figure 7 As shown, the registration process for the first module includes:

[0157] 201: The first module manager obtains the module identifier of the module to be registered, such as the identifier of the first module.

[0158] 202: The first module manager determines whether the first module has been registered based on its identifier. Specifically, it determines whether the identifier ID of the first module is the same as one of the multiple module IDs that are locally counted and stored.

[0159] 203: If so, an error message will be returned indicating that registration has failed, because two modules are trying to register using the same module identifier ID, while each functional module can only use a unique identifier ID.

[0160] 204: If not, then determine whether the first module manager is a kernel space module manager. Typically, there is only one kernel space module manager.

[0161] 205: If it is a module manager in kernel space, a module registry is generated based on the identifier ID of the first module (such as the module number), all the functions contained in the first module, and the function identifier corresponding to each function (such as function A1, A2, B1), and the module registry is stored in the storage medium of the first module manager.

[0162] 206: If no, i.e., the first module manager is not a module manager in kernel space, then send all methods / functions contained in the first module manager (including the identifier ID of the first module, all functions contained in the first module, and the function identifier corresponding to each function) to the module manager in kernel space. The module manager in kernel space is referred to as the second module manager.

[0163] After receiving all methods / functions from the first module manager, the second module manager registers the first module based on the relevant information from the first module manager and generates a module registry. Additionally, the second module manager sends feedback to the first module manager indicating whether the registration was successful or failed.

[0164] 207: The first module manager determines whether it has received a registration success indication from the second module manager.

[0165] If so, it confirms that the second module manager has completed the registration of the first module successfully. It then stores the relevant information of the first module, the module registry, etc., locally, following the same process as step 205.

[0166] 208: If the first module manager receives a registration failure indication from the second module manager, it determines that the registration of the method functionality of the first module has failed.

[0167] This method registers the functions of each of the split functional modules in the module manager and establishes a module registry in the module manager, thereby providing a basis for finding the target module that can provide the corresponding functions to the requester.

[0168] It should be understood that the registration methods for other module managers can be found by referring to [the relevant documentation / reference]. Figure 7 The method flow shown in this embodiment does not elaborate on the registration process of other module managers.

[0169] Optionally, in the above registration process, the method further includes: assembling the interfaces of each functional module to obtain the calling interface of each functional module, so as to provide the calling interface of the target module when one of the functional modules is found as the target module.

[0170] One specific implementation is that, during module registration, or when the user-space module manager synchronizes a new module from the kernel-space module manager, or when the kernel-space module manager receives a request from the user-space module manager to register to user space, the calling interface can be assembled using the following method (see [link to relevant documentation]). Figure 8 This embodiment uses the module manager that initiates the registration request as the first module manager for illustration, and the method includes:

[0171] Step 204: Determine whether the first module manager is a kernel space module manager, followed by:

[0172] If the first module manager is a kernel space module manager, then it is determined whether the target module manager of the requested functional service from the target module is in the same address space as the first module manager, that is, whether the target module manager is also a kernel space module manager. If so, it means that the first module manager and the target module manager are the same module manager and are both kernel module managers. At this time, call interfaces in the same address space are assembled.

[0173] If not, it means that the target module manager is a user-space module manager, which is in a different address space from the first module manager. The target module is in user space, and the first module is in kernel space. Kernel mode calls user-space functions. At this time, the calling interface of the target module is the calling interface of the assembled user space.

[0174] In step 204 above, if it is determined that the first module manager is a module manager in user space, then it is further determined whether the first module manager and the target module manager are in the same address space. If so, it means that the target module manager and the first module manager are located in the same user space and belong to the same user space capability call. At this time, the call interface of the target module is the call interface that assembles the same address space.

[0175] If the target module manager and the first module manager have different address spaces, it is further determined whether the target module manager is located in the address space of another user space. If so, it means that the target module manager and the first module manager are both located in user space, but belong to different user address spaces, and a cross-user space call interface is assembled. If not, it means that the target module manager is not in user space, but in kernel space, and a user-mode call to kernel-mode scenario occurs. In this case, the call interface of the target module is the call interface for assembling kernel space.

[0176] After composing the call interfaces for all the above scenarios, so that... Figure 5 In step 103 shown, the first module manager obtains the calling interface of the target module.

[0177] During the registration phase, this method assembles interfaces for the module managers of each functional module so that they can be used in the process of calling interface functions, thereby improving the efficiency of obtaining interface calls and saving calling time.

[0178] In one specific implementation, step 103 of this embodiment will be described below in conjunction with the registration process and interface assembly process described above. See also Figure 9 The process by which the first module requests to call the function of another module and obtains the calling interface for that function is as follows:

[0179] 301: The first module sends a request through its module manager (let's say the first module manager) to obtain a functional service.

[0180] 302: The first module manager determines whether its location is in user space.

[0181] 303: If yes, meaning the first module manager is located in user space, then determine whether the first module has been registered in the first module manager. The specific determination process is the same as step 202 above.

[0182] For example in Figure 6 In the example, the first module is functional module B. Functional module B sends a request to the first module manager. After receiving the request, the first module manager determines that it is deployed in user space 1. Then, the first module manager determines whether functional module B already exists. If it does not exist, step 304 is executed; if it exists, step 306 is executed.

[0183] 304: If not, i.e. not registered, then perform module synchronization with the module manager in kernel space.

[0184] For example, the first module manager sends a synchronization request to the target module manager in the kernel space, reporting all functional methods of functional module B in the first module manager to the target module manager. Similarly, the target module manager also sends all functional methods of kernel module 1 and kernel module 2 to the first module manager, thus completing the data synchronization between the two module managers.

[0185] 305: Determine whether the first module has been successfully registered in the first module manager.

[0186] 306: If so, locate the target module and check its permissions to determine if the target module has the necessary permissions. The specific process for locating the target module is described in step 102 above, and will not be repeated here.

[0187] Additionally, in step 305, if it is determined that the first module has not been successfully registered, then the corresponding target module has not been found, and the search has failed.

[0188] 307: Following step 306, if the permission check of the target module is successful, determine whether the target module's calling interface has been assembled. For the specific assembly process, please refer to the previous section. Figure 8 The descriptions of the corresponding embodiments are not repeated here.

[0189] 308: If it is determined in step 307 that a calling interface has been assembled, then obtain and save the calling interface.

[0190] 309: The first module manager obtains the saved call interface and returns the call interface to the first module.

[0191] In addition, if the calling interface is not assembled in step 307, the corresponding calling interface is found or assembled, and then the calling interface is fed back to the first module.

[0192] This method only relies on the module access interface provided by the module manager, which can decouple modules. Even if the requested functional module does not exist, appropriate processing can be performed after the request to the module manager fails, avoiding the hard dependencies before splitting.

[0193] The process of splitting each driver in the operating system into at least one independent functional module before step 101 of the above embodiment will be described below.

[0194] like Figure 3 The diagram shows the method call relationship between two kernel modules in the kernel space when they are not separated. Figure 4 The diagram shows the multiple functional modules resulting from the breakdown of the kernel module. Specifically, from... Figures 3 to 4The splitting process can be implemented using the following methods. This embodiment takes the splitting of kernel module 1 (i.e., driver A1) in the kernel space as an example. The method includes:

[0195] Step 1: Obtain the interface set contained in kernel module 1. The interface set includes at least one interface. In this example, the interface set of kernel module 1 includes: a first interface (InterfaceFuncA) and a second interface (InterfaceFuncB).

[0196] Step 2: Obtain the methods that each interface in the interface set can call and the calling relationships between the methods.

[0197] Specifically, by analyzing the syntax tree, all methods that InterfaceFuncA and InterfaceFuncB can call are obtained. In this example, through syntax tree analysis, the methods that InterfaceFuncA can call are: method 1 (InnerFunc1), method 2 (InnerFunc2), and method 3 (InnerFunc3). The methods that InterfaceFuncB can call are: method 2 (InnerFunc2) and method 3 (InnerFunc3).

[0198] Step 3: Generate the first-level structure based on the methods that each interface can call and the calling relationships.

[0199] The first-level structure can also be called the "call tree".

[0200] like Figure 10 As shown, a hierarchical deployment structure is adopted, with each interface module as a unit. The structure, from top to bottom, consists of the included interfaces, the first level of the call tree, the second level of the call tree, and so on. Specifically, the functions that the first interface, InterfaceFuncA, can call are classified as "Functional Module A," and the functions that the second interface, InterfaceFuncB, can call are classified as "Functional Module B." The first level of the call tree contains the methods that InterfaceFuncA and InterfaceFuncB can directly call. For example, if InterfaceFuncB can only directly call InnerFunc3, then InnerFunc3 is placed in the first level of the call tree; while InnerFunc3 can directly call InnerFunc2, then InnerFunc3 is placed in the second level of the call tree.

[0201] Similarly, since InterfaceFuncA can directly call methods InnerFunc1 and InnerFunc2, these two methods are placed in the first level of the call tree; InnerFunc2 can call InnerFunc3, so InnerFunc3 is placed in the second level of the call tree.

[0202] It should be understood that the first-level structure described above can also be represented in other ways, such as using a "binary tree structure". This embodiment does not limit the representation of the methods that can be called by each of the above interfaces and the form of the calling relationship.

[0203] Step 4: If there are duplicate method functions in the first hierarchical structure, then the duplicate method functions are removed to obtain the second hierarchical structure.

[0204] Specifically, it determines whether there are calls to the same method function in two or more interfaces of the first-level structure. If so, the same method function is deleted, and only one of the method functions is kept. Thus, when trimming functional modules, the same method function is called by two or more interfaces, which in turn affects each other.

[0205] In one possible implementation, it's determined whether the method functions at each level of functional module B have the same function functions in other interface functional modules. For example, it's determined whether the method functions at each level of functional module B have the same function functions in functional module A. The determination shows that the method function `InnerFunc3` at the first level of the call tree of functional module B is the same as `InnerFunc3` at the second level of the call tree of functional module A. The method function `InnerFunc2` at the second level of the call tree of functional module B is the same as `InnerFunc2` at the first level of the call tree of functional module A. Therefore, the duplicate method functions "InnerFunc2" and "InnerFunc3" need to be deleted, keeping only "InnerFunc2" and "InnerFunc3" in one functional module.

[0206] The splitting principle is to judge step by step according to the following three parameters, specifically including:

[0207] (1) Determine the average number of times n a method function in the current functional module is called during the business call process, select the method function with the larger average number of times n is called as the retained method function, and delete the method function in the functional module with the smaller value of n;

[0208] (2) If the average number of calls n is the same, then determine the calling status of the method function in each functional module. The calling status includes mandatory calls and conditional calls, and mandatory calls have higher priority than conditional calls. If one method function is in the mandatory call status and the others are in the conditional call status, then the method function corresponding to the mandatory call status is determined to be the method function that needs to be retained, and the remaining method functions in the conditional call status need to be deleted.

[0209] (3) If the same method function being detected has the same call status, or if two or more method functions have the same call status, such as two method functions being in a guaranteed call status, then the decision on whether to retain the function is based on the priority of the business being called for each method function.

[0210] For example, if the business importance or priority of the method function InnerFunc2 in the second level of the call tree of functional module B is higher than that of the method function InnerFunc2 in the first level of the call tree of functional module A, then it is determined to retain the method function InnerFunc2 in functional module B and delete InnerFunc2 in functional module B.

[0211] For example, according to the above splitting principles, Figure 10 The first-level structure shown is broken down to obtain the second-level structure, as follows: Figure 11 As shown. The interface `InterfaceFuncB` of functional module B contains the directly callable method function `InnerFunc3`, while the deleted method function `InnerFunc2` can be invoked by requesting an invocation from the interface `InterfaceFuncA2` of functional module A. Similarly, for functional module A, when it needs to invoke the method function `InnerFunc3`, it needs to request an invocation from the interface `InterfaceFuncB` of functional module B.

[0212] Step 5: Deploy independent functional modules according to the second-level structure to complete the splitting and deployment of the driver.

[0213] In this embodiment, according to Figure 11 The second-level organizational deployment function module shown above yields the above results. Figure 4 Kernel module 1 is shown.

[0214] It should be understood that the above-described driver splitting process applies not only to kernel space but also to user space. Specifically, the splitting and deployment process of user space drivers can be the same as the splitting process of kernel module 1 described above, and will not be repeated in this embodiment.

[0215] The splitting and deployment method provided in this embodiment decouples the calling relationships between various drivers. After deployment, each functional module can be arbitrarily trimmed without causing compilation, linking, or runtime anomalies.

[0216] Additionally, the method in the above embodiments further includes: moving functional modules from kernel space to user space. For example, moving... Figure 6 The functionality of kernel module 2 shown is moved to user space. One possible implementation includes:

[0217] S1: Deploy the first process in user space. The first process is either a user-mode process or a user-space process.

[0218] S2: Deploy the functional module C of kernel module 2 in the functional module corresponding to the first process, and add a new module manager to the functional module of the first process to manage and call all or part of the functions of functional module C.

[0219] S3: Delete functional module C from the original kernel space and all functions in the kernel space's target module manager that call functional module C. Because this functionality has been moved to the new module manager, the corresponding functions must be deleted from the target module manager.

[0220] like Figure 12 As shown, to... Figure 6 The diagram shown illustrates the process of moving functional module C from kernel space to user space. Additionally, after deployment, the process includes: synchronizing modules between the new module manager and the original target module manager. Once synchronization is complete, each module manager will automatically assemble and return different module call interfaces based on the deployment locations of the requester and the requested party.

[0221] Furthermore, the technical solutions for any of the following scenarios are the same as the method steps in the foregoing embodiments, as can be found above. Figure 5 , Figures 7 to 9 The method flow of the embodiment includes any of the following scenarios:

[0222] When functional module C in user space 2 wants to call function A1 or function A2 in kernel module 1;

[0223] When functional module C in user space 2 wants to call functional B1 in user space 1;

[0224] When functional module A in kernel module 1 wants to call functional B1 in user space 1;

[0225] When functional module A in kernel module 1 wants to call functional C1 in user space 2.

[0226] Because these interfaces have the same calling parameters, functional modules using these interfaces are unaware of their differences. When a functional module migrates from kernel space to user space, it allows the kernel module to be moved to user space without modifying a single line of code in the functional module, enabling flexible deployment of functional modules in both kernel and user spaces.

[0227] In this embodiment, when a functional module needs to be moved from user space to kernel space, or vice versa, because the modules no longer have dependencies on each other after being split and deployed, they only depend on the calling interfaces provided by their respective module managers and use the same parameters. Therefore, the function calls between modules are completely unaware of this change. By utilizing the module manager for each functional module, the deployment location of the functional module can be flexibly migrated without modifying the module's code.

[0228] The following describes the apparatus embodiments corresponding to the above method embodiments.

[0229] Figure 13 This is a schematic diagram of a module manager provided in an embodiment of this application. The module manager is generated by the system when it splits at least one driver into at least one independent functional module. The module manager registers relevant information of at least one functional module, and the module manager can implement the functional debugging method in the foregoing embodiments.

[0230] Specifically, such as Figure 13 As shown, the module manager includes a receiving unit 1301, a processing unit 1302, and a sending unit 1303. Furthermore, the module manager may also include other units or modules such as a storage unit. This embodiment does not limit this to such units.

[0231] The receiving unit 1301 is used to receive a first request message sent by the first module, the first request message including an identifier of a first functional service; the processing unit 1302 is used to search for a target module in the module registry according to the identifier of the first functional service, and to obtain the calling interface of the target module, the module registry including the correspondence between the identifier of the first functional service and the target module, the target module being used to provide the first functional service to the first module; the sending unit 1303 is used to send the calling interface of the target module to the first module.

[0232] Optionally, in a specific implementation of this embodiment, the processing unit 1302 is further configured to search for a functional module that can provide the first functional service in the module registry according to the identifier of the first functional service, and determine the functional module that can provide the first functional service as the target module.

[0233] Optionally, in another specific implementation of this embodiment, the processing unit 1302 is further configured to determine the target module manager where the target module is located; determine the calling mode based on the location of the target module manager and the location of the first module manager; and determine the calling interface of the target module based on the calling mode and the correspondence between the calling mode and the calling interface.

[0234] Optionally, in another specific implementation of this embodiment, the module manager corresponding to the first module is a first module manager, and the location of the first module manager is in kernel space or user space; when the location of the target module manager is in the same address space as the location of the first module manager, the calling mode is a same address space call. The processing unit 1302 is further configured to determine, when the calling mode is a same address space call, that the calling interface of the target module includes a method for directly accessing the address of the target module and the address of the target module.

[0235] Optionally, in another specific implementation of this embodiment, when the location of the target module manager is in a different address space than the location of the first module manager, the calling mode is either user space calling kernel space, or kernel space calling user space.

[0236] The processing unit 1302 is further configured to, when the calling mode is user space calling kernel space, determine the calling interface of the target module by: initiating a call to the kernel space interface using a method provided by the operating system, and the interface data required to call the kernel space interface; and when the calling mode is kernel space calling user space, determine the calling interface of the target module by: initiating a call to the user space interface using a method provided by the operating system, and the interface data required to call the user space interface.

[0237] Optionally, in another specific implementation of this embodiment, when the location of the first module manager is in the first user space and the location of the target module manager is in the second user space, the calling mode is an address space call between users. The processing unit 1302 is further configured to determine the calling interface of the target module when the calling mode is an address space call between users, including: initiating a call to the second user space interface using an inter-process method of the operating system, and the interface data required to call the second user space interface.

[0238] Optionally, in another specific implementation of this embodiment, the processing unit 1302 is further configured to determine whether the first module has been registered in the first module manager before obtaining the calling interface of the target module; if not, and the first module manager is a kernel space module manager, then register and save the relevant information of the first module, the relevant information of the first module including: the identifier of the first module, all functions contained in the first module, and the function identifier corresponding to each function.

[0239] Optionally, in another specific implementation of this embodiment, the processing unit 1302 is further configured to register the relevant information of the first module to the module manager of the kernel module if the first module manager is a user space module manager; and to determine that the first module has been successfully registered in the module manager of the kernel space when the receiving unit receives an instruction sent by the module manager of the kernel space.

[0240] In addition, in the specific hardware implementation, this embodiment also provides an electronic device, which can be a terminal device, such as a smartphone, laptop, tablet, PC, foldable terminal, etc., which can be used to implement the function calling method in the foregoing embodiment.

[0241] In this embodiment, when the electronic device is used as a terminal device, it can achieve the functions described in the foregoing embodiments. Figure 5 , Figures 7 to 9 The steps are shown.

[0242] When the electronic device is a terminal device, its structural composition is the same as described above. Figure 2 The terminal devices shown have the same structure. They include components such as a processor 110, a memory 120, and at least one interface, wherein, for example... Figure 13 In the module manager shown, the functions of the receiving unit 1301, processing unit 1302, and sending unit 1303 can be implemented by the processor 110 of the terminal device and at least one interface; the function of the storage unit can be implemented by the memory 120 of the terminal device.

[0243] Furthermore, embodiments of this application also provide a function call system, such as... Figure 14 As shown, the system includes a first module 1401, a first module manager 1402, and a target module 1403. The first module 1401 is the module that requests to invoke a certain function, the module whose function is invoked is the target module 1403, and the first module manager 1402 is the module manager of the first module 1401.

[0244] The structures of the first module 1401 and the target module 1403 can be the same as those described above. Figure 2The terminal devices shown may have the same structure or different structures. This embodiment does not limit the structure and specific form of each module.

[0245] In addition, the system provided in this embodiment is also used to split the operating system driver into at least one independent functional module, and to manage the split functional modules by different module managers, thereby realizing function calls between modules.

[0246] The function call system provided in this embodiment pre-divides the system's driver module into smaller granular function modules. The divided function modules are independent of each other and are not coupled to each other. They then communicate through synchronous messages, asynchronous messages, and one-way messages, enabling each function module to access or obtain the relevant functions of other function modules by calling the interface.

[0247] Furthermore, since the various functional modules are independent of each other, and the functional code only depends on the functional module access interface provided by the module manager, the functional modules can be arbitrarily trimmed. Even if other functional modules that a functional module needs to access are trimmed, a response can still be made after the request to the target functional module manager fails, without causing compilation, linking, or runtime exceptions, thus overcoming the problems of difficult driver construction, trimming, and maintenance.

[0248] Furthermore, embodiments of this application also provide a computer storage medium, wherein the computer storage medium may store a program, and the program, when executed, may include some or all of the steps of the function call method provided in this application. The storage medium includes, but is not limited to, magnetic disks, optical disks, read-only memory (ROM), or random access memory (RAM), etc.

[0249] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product.

[0250] The computer program product includes one or more computer instructions, such as pairing instructions or transmission instructions, which, when loaded and executed by a computer, generate, in whole or in part, the method flows or functions described in the foregoing embodiments of this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0251] Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. Additionally, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0252] The embodiments described above do not constitute a limitation on the scope of protection of this application.

Claims

1. A function call method, characterized by, The method is applied to a system comprising at least one driver, each of the drivers is split into at least one independent functional module, each of the functional modules is registered to a corresponding module manager, and the method comprises: receiving a first request message sent by a first module, the first request message comprising an identifier of a first functional service, the first module being any one of the functional modules; finding a target module in a module registry according to the identifier of the first functional service, the module registry comprising a correspondence between the identifier of the first functional service and the target module, the target module being configured to provide the first functional service for the first module, and the target module belonging to the functional modules; obtaining a calling interface of the target module; sending the calling interface of the target module to the first module.

2. The method of claim 1, wherein, The method further comprises: finding a functional module capable of providing the first functional service in the module registry according to the identifier of the first functional service, and determining the functional module capable of providing the first functional service as the target module.

3. The method according to claim 1 or 2, characterized in that, The method further comprises: determining a target module manager in which the target module is located; determining a calling mode according to a location of the target module manager and a location of a first module manager; determining the calling interface of the target module according to the calling mode and a correspondence between the calling mode and the calling interface.

4. The method of claim 3, wherein, The module manager corresponding to the first module is the first module manager, and the location of the first module manager is in a kernel space or a user space; when the location of the target module manager and the location of the first module manager are in a same address space, the calling mode is same address space calling; The method further comprises: when the calling mode is same address space calling, the calling interface of the target module comprises a method of directly accessing a target module address and the target module address.

5. The method of claim 4, wherein, when the location of the target module manager and the location of the first module manager are in different address spaces, the calling mode is user space calling kernel space or kernel space calling user space; The method further comprises: when the calling mode is user space calling kernel space, the calling interface of the target module comprises a method of initiating calling of the kernel space interface using an operating system and interface data required for calling the kernel space interface; when the calling mode is kernel space calling user space, the calling interface of the target module comprises a method of initiating calling of the user space interface using an operating system and interface data required for calling the user space interface.

6. The method of claim 4, wherein, when the location of the first module manager is in a first user space and the location of the target module manager is in a second user space, the calling mode is address space calling between different users, The method further comprises: When the calling mode is cross-address space calling between users, the calling interface of the target module comprises: initiating the calling of the second user space interface using a method between operating system processes, and interface data required for calling the second user space interface.

7. The method according to claim 1 or 2, characterized in that, Before the obtaining of the calling interface of the target module, the method further comprises: determining whether the first module has been registered in the first module manager; if not, and the first module manager is a module manager in a kernel space, registering and saving relevant information of the first module, the relevant information of the first module comprising: an identifier of the first module, all functions contained in the first module, and a function identifier corresponding to each function.

8. The method of claim 7, wherein, The method further comprises: if the first module manager is a module manager in a user space, registering the relevant information of the first module to a module manager in a kernel space; when receiving an indication sent by the module manager in the kernel space, determining that the first module is successfully registered in the module manager in the kernel space.

9. A module manager, characterized by The module manager is generated when at least one driver is split into at least one independent function module by a system, the module manager registering relevant information of at least one function module, the module manager comprising: a receiving unit configured to receive a first request message sent by a first module, the first request message comprising an identifier of a first function service, the first module being any one of the function modules; a processing unit configured to find a target module in a module registration table according to the identifier of the first function service, and obtain a calling interface of the target module, the module registration table comprising a correspondence between the identifier of the first function service and the target module, the target module being configured to provide the first function service for the first module, and the target module belonging to the function modules; a sending unit configured to send the calling interface of the target module to the first module.

10. The module manager of claim 9, wherein: the processing unit is further configured to find a function module capable of providing the first function service in the module registration table according to the identifier of the first function service, and determine that the function module capable of providing the first function service is the target module.

11. The module manager according to claim 9 or 10, characterized in that, the processing unit is further configured to: determine a target module manager in which the target module is located; determine a calling mode according to a position of the target module manager and a position of the first module manager; determine the calling interface of the target module according to the calling mode and a correspondence between calling modes and calling interfaces.

12. The module manager of claim 11, wherein, the module manager corresponding to the first module is the first module manager, and the position of the first module manager is in a kernel space or a user space; when the position of the target module manager and the position of the first module manager are in the same address space, the calling mode is same-address space calling; the processing unit is further configured to, when the calling mode is same-address space calling, determine that the calling interface of the target module comprises a method of directly accessing a target module address and the target module address.

13. The module manager of claim 11, wherein, when the location of the target module manager and the location of the first module manager are different address spaces, the calling mode is user space calling kernel space, or kernel space calling user space; the processing unit is further configured to: when the calling mode is user space calling kernel space, determining the calling interface of the target module includes initiating a call to the kernel space interface using a method provided by an operating system, and interface data required for calling the kernel space interface; when the calling mode is kernel space calling user space, determining the calling interface of the target module includes initiating a call to the user space interface using a method provided by an operating system, and interface data required for calling the user space interface.

14. The module manager of claim 12, wherein, when the location of the first module manager is in a first user space and the location of the target module manager is in a second user space, the calling mode is cross-user address space calling, the processing unit is further configured to, when the calling mode is cross-user address space calling, determine the calling interface of the target module includes initiating a call to the second user space interface using a method between processes of an operating system, and interface data required for calling the second user space interface.

15. The module manager of claim 9 or 10, wherein the processing unit is further configured to, before obtaining the calling interface of the target module, determine whether the first module has been registered in the first module manager; if not, and the first module manager is a kernel space module manager, register and save relevant information of the first module, the relevant information of the first module including an identifier of the first module, all functions contained in the first module, and a function identifier corresponding to each function.

16. The module manager of claim 15, wherein the processing unit is further configured to, if the first module manager is a user space module manager, register the relevant information of the first module to a kernel space module manager; and, when an indication sent by the kernel space module manager is received by the receiving unit, determine that the first module is successfully registered in the kernel space module manager.

17. A module management apparatus characterized by comprising: comprising: a processor and a memory, the processor being coupled to the memory; the memory is configured to store computer program instructions; the processor is configured to execute the instructions stored in the memory, so that the apparatus executes the method of any one of claims 1 to 8.

18. A capability invocation method, comprising: comprising at least one functional module and at least one module manager, the at least one functional module being generated after being split by at least one driver of a system, and the at least one module manager registering relevant information of the at least one functional module; the method comprising: a first module sending a first request message to a first module manager, the first request message including an identifier of a first function service, the first module being any one of the functional modules; the first module manager receiving the first request message, determining the calling interface of the target module based on the first request message, and sending a second request message to the target module, the second request message including the identifier of the first function service. The first module manager receives the first request message, finds a target module in a module registry according to the identification of the first function service, obtains a calling interface of the target module, and sends the calling interface of the target module to the first module, the module registry including a corresponding relationship between the identification of the first function service and the target module, and the target module belonging to the function module; The first module receives the calling interface of the target module, and requests the first function service from the target module by using the calling interface of the target module.

19. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 1 to 8.

20. A computer program product that, when executed on a computer, causes the computer to perform the method of any one of claims 1 to 8.

Images