System service calling method and computer equipment

Abstract

The embodiment of the invention provides a system service calling method and computer equipment, can be applied to the technical field of computer user mode service calling, and comprises the following steps: determining n system service processes according to a user process, the method comprises the following steps of: acquiring n system service processes, and copying respective target information segments (such as code segments / data segments) of the n system service processes to n address spaces within a preset range in a user process, when the user process merged with the target information segments calls a first process (the first process belongs to the n system service processes); and carrying out service calling on the first process in the user process in a function calling mode. According to the method, different system service processes are merged into the address space of the same process (namely the user process), so that mutual calling is facilitated; the problem of IPC performance bottleneck during user service calling is solved, and performance improvement is achieved by bypassing an IPC process; in addition, code modification does not need to be carried out on an original system service process, so that wide use is facilitated, and application universality is achieved.

Description

Technical Field

[0001] This application relates to the field of computer user-mode service invocation technology, and in particular to a method for invoking system services and a computer device. Background Technology

[0002] In a computer system, the operating system kernel provides users with services that require the operating system to perform. Users can request these services from the operating system through access requests provided by the operating system, passing parameters and returning values ​​according to regulations. This behavior is called a system service call, or simply a system call. Users can add, delete, or modify the functionality of the operating system kernel according to their needs, making the operating system's functionality better suit their requirements. This behavior is called a kernel extension. Compared to system services integrated into the operating system kernel, kernel extensions are easier to develop and offer better security.

[0003] To enable user-mode system service calls, the industry generally adopts the following approach: the service user (i.e., the user process) transmits parameters and required data to the service program (i.e., the system service process) in a prescribed manner through inter-process communication (IPC). After being awakened, the service program processes the transmitted parameters and data and returns the result to the service user through IPC after processing.

[0004] The speed of service calls via IPC is limited by the performance of IPC, which is often slow, making it a bottleneck in the entire service process. This is because IPC requires switching between processes (i.e., between user processes and system service processes), and the process switching involves complex and cumbersome tasks, making it difficult to further reduce the time of the IPC process. Summary of the Invention

[0005] This application provides a method for invoking system services and a computer device for merging different system service processes into the address space of the same process (i.e., the user process), thereby facilitating mutual invocation and solving the IPC performance bottleneck problem when users make system service calls. Performance is improved by bypassing the IPC process (because the execution time of IPC calls is still longer than that of function calls, and the duration of thousands of clock cycles is the bottleneck for system service calls). Furthermore, this application does not require code modification to the original system service processes, thus facilitating widespread use and possessing universal applicability.

[0006] Based on this, the embodiments of this application provide the following technical solutions:

[0007] Firstly, this application provides a method for invoking system services. Specifically, the method includes: First, a computer device determines n system service processes to be merged based on the current user process (referred to as the first user process), where n ≥ 1. These n system service processes can be determined by the user analyzing the code of the first user process, or the computer device can directly determine them based on the type of the first user process; this application does not limit this. Next, the computer device further copies the target information segments of each of the n determined system service processes to n preset address spaces within the first user process (i.e., a memory space from address a to address b, such as a memory space between addresses 1000 and 2000), resulting in a second user process. Each system service process corresponds to one preset address space. It should be noted that the sizes of the n preset address spaces can be the same or different; this application does not limit this. Finally, when the second user process calls the first process, the second user process invokes the service of the first process through a function call. The first process is one of the n system service processes.

[0008] In the above embodiments of this application, functions that would normally need to be implemented in the programmable kernel are placed in user space (i.e., user processes). This involves merging different system service processes into the address space of the same process, enabling fast and secure operation of system services. This application addresses the IPC performance bottleneck problem when user processes perform system calls by converting IPC calls into function calls, thereby improving performance by bypassing the IPC process. Furthermore, this application can implement the functionality of the programmable kernel without modifying the source code of the system service processes, making it more flexible and convenient in application.

[0009] In one possible implementation of the first aspect, after copying the target information segments of each of the n system service processes to the address spaces of the n preset ranges within the first user process, the method may further include: recording the status information of each of the n system service processes in the n pre-allocated management units (also referred to as management structures), with one management unit corresponding to one system service process.

[0010] In the above embodiments of this application, in addition to pre-allocating n preset address spaces for these n system service processes, n management units can also be pre-allocated for these n system service processes. Each management unit records relevant information about the operation of each system service process for use in subsequent function calls.

[0011] In one possible implementation of the first aspect, the state information may be at least any one of the following: 1) the start address and / or end address of the target information segment corresponding to each system service process in the second user process (i.e., the specific location of the target information segment within its allocated preset address space); 2) the data size of the target information segment corresponding to each system service process (i.e., the size of the memory occupied by the target information segment within its allocated preset address space); 3) the function and / or function number corresponding to the target information segment corresponding to each system service process (e.g., how many functions correspond to, their respective function names, function numbers, etc.), with each specific function corresponding to the implementation of a function; 4) the value of the register corresponding to each system service process.

[0012] In the above embodiments of this application, the types of information that the status information can be are specifically described, which has universality.

[0013] In one possible implementation of the first aspect, one way to make service calls to the first process within the second user process via function calls is as follows: within the second user process, based on the status information recorded in the first management unit, the first management unit is the management unit corresponding to the first process.

[0014] In the above embodiments of this application, the address of the function to be called is obtained according to the status information recorded in the first management unit corresponding to the second user process, thereby realizing jump execution and realizing the fast and safe operation of system services.

[0015] In one possible implementation of the first aspect, after determining n system service processes based on the first user process, the method may further include: performing address isolation processing (such as software fault isolation (SFI)) on the n system service processes so that the address space in which each system service process runs is limited to a specified size.

[0016] In the above embodiments of this application, the purpose of address isolation processing is to ensure that the running logic of the system service process code will only use the address space within a specified size range, thereby limiting the running address space of the system service process to a specified size range, ensuring that the target information segment will not cause address conflicts with the code of other processes after being copied to the first user process, thus avoiding process crashes.

[0017] In one possible implementation of the first aspect, after determining n system service processes based on the first user process, the method may further include: modifying the link libraries of each of the n system service processes to convert inter-process communication (IPC) calls into function calls.

[0018] In the above embodiments of this application, by modifying the link library used by the system service process, the execution logic of the IPC specified in the process is converted into a function call. This can achieve the conversion of IPC calls in the system service call into function calls without changing the source code of the process, thus satisfying the merged process call logic.

[0019] In one possible implementation of the first aspect, after determining n system service processes based on the first user process, the method may further include: assigning a process ID to each system service process in the second user process, the process ID being used to identify the corresponding system service process.

[0020] In the above embodiments of this application, the process number serves as a unique identifier for the system service process within the second user process, and is used to accurately identify and invoke the corresponding system service process in subsequent operations, thereby improving accuracy.

[0021] In one possible implementation of the first aspect, after copying the target information segments of each of the n system service processes to the address spaces of the n preset ranges within the first user process, the method may further include: in the case of the second process calling the third process, the service call to the third process can be completed through the forwarding function in the second user process, wherein the second process and the third process are any two of the aforementioned n system service processes.

[0022] In the above embodiments of this application, system service processes can also call each other's system services through forwarding functions, which provides flexibility.

[0023] In one possible implementation of the first aspect, the target information segment of each copied system service process can be a target code segment (also known as a critical code segment), a target data segment (also known as a critical data segment), or both a target code segment and a target data segment. This application does not limit the specific implementation of this. The target data segment is the data required by the target code segment at runtime.

[0024] In the above embodiments of this application, the types of target information segments to be copied are specifically described, which has broad applicability.

[0025] A second aspect of this application provides a computer device having the function of implementing the method of the first aspect or any possible implementation thereof. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0026] A third aspect of this application provides a computer device that may include a memory, a processor, and a bus system. The memory is used to store a computer program (also referred to as a program or computer-readable instructions), and the processor is used to invoke the program stored in the memory to execute the method of the first aspect of the embodiments of this application or any possible implementation of the first aspect.

[0027] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a computer, enable the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0028] The fifth aspect of this application provides a computer program or a computer program product containing instructions that, when the computer program or computer program product is run on a computer, causes the computer to perform the method described in the first aspect or any possible implementation of the first aspect.

[0029] A sixth aspect of this application provides a chip including at least one processor and at least one interface circuit coupled to the processor. The interface circuit performs transceiver functions and sends instructions to the at least one processor. The at least one processor runs a computer program or instructions, having the functionality to implement the methods described in the first aspect or any possible implementation of the first aspect. This functionality can be implemented in hardware, software, or a combination of hardware and software, including one or more modules corresponding to the described functions. Furthermore, the interface circuit is used to communicate with other modules outside the chip.

[0030] In some implementations of this application, some of the one or more processors may implement some steps of the above method through dedicated hardware. For example, the processing involving neural network models may be implemented by a dedicated neural network processor or graphics processor.

[0031] The method provided in this application embodiment can be implemented by a single chip or by multiple chips working together. Attached Figure Description

[0032] Figure 1 A schematic diagram of the system architecture provided in the embodiments of this application;

[0033] Figure 2 A schematic diagram illustrating the implementation of the system service invocation method provided in the embodiments of this application in platform software and server hardware;

[0034] Figure 3 A flowchart illustrating the method for invoking system services provided in this application embodiment;

[0035] Figure 4 A component structure example diagram of the system service invocation method provided in the embodiments of this application;

[0036] Figure 5 A flowchart illustrating the implementation of step (i) in the embodiments of this application;

[0037] Figure 6 A flowchart illustrating the implementation of step (ii) in the embodiments of this application;

[0038] Figure 7 A flowchart illustrating the implementation of step (iii) in the embodiments of this application;

[0039] Figure 8 A flowchart illustrating the implementation of step (iv) in the embodiments of this application;

[0040] Figure 9 A flowchart illustrating the implementation of step (v) in the embodiments of this application;

[0041] Figure 10 A schematic diagram of a computer device provided in an embodiment of this application;

[0042] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0043] This application provides a method for invoking system services and a computer device, which allows functions that would otherwise need to be implemented in a programmable kernel to be placed in user space (i.e., user processes). This involves merging different system service processes into the address space of the same process, enabling fast and secure operation of system services. This application addresses the IPC performance bottleneck problem when user processes perform system calls by converting IPC calls into function calls, thereby improving performance by bypassing the IPC process. Furthermore, this application can implement the functionality of a programmable kernel without modifying the source code of the system service processes, making it more flexible and convenient in application.

[0044] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0045] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0046] First, the system architecture and overall process applied in the methods of the embodiments of this application will be described. For details, please refer to [link / reference needed]. Figure 1 , Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application. The system architecture may include: a user process 101, a server process 102, an operating system kernel 103, an application (APP) 104, a file system (FS) 105, a driver 106, etc. The user process 101 is a user process that incorporates the target information segment (also called a critical information segment) of the system server process 102. There may be one or more system server processes 102; this application does not limit this. Figure 1 For illustrative purposes only.

[0047] The following is about Figure 1 The functions of each unit / module in the system architecture shown are described below:

[0048] (1) User process 101

[0049] User process 101 is a user-mode process and, in this application, is a user of the system service, also known as a caller. This user process 101 is a user process that merges the system service's target information segment. User process 101 isolates the target information segment of the original system service process 102 by address isolation (i.e.,...). Figure 1 The system service process (SFIed) in the address isolation can be SFI, and then merged into the user process 101 itself, so as to realize the fast calling of system services through function calls.

[0050] (2) System service process 102

[0051] In this application, system service process 102 is a service program that provides system services. System service process 102 is the original system service process, which is the process that initially waits for user processes to call and provides service functions.

[0052] (3) Operating system kernel 103

[0053] Operating system kernel 103 provides users with basic IPC communication and other functions.

[0054] (4) APP 104

[0055] APP 104 is a third-party application on the hardware device of this application, providing users with an internet access point to meet their needs.

[0056] (5)FS105

[0057] In computer devices, a file system (FS) is a method for managing and organizing data. It defines how files and directories are named, stored, and accessed. File systems can operate on hard drives, flash memory, or other storage media, enabling users to create, read, modify, and delete files.

[0058] (6) Drive 106

[0059] A driver is a small piece of code added to the operating system that contains information about a hardware device. With this information, the computer device can communicate with other devices. Drivers are configuration files written by hardware manufacturers for the operating system; without drivers, the hardware in a computer cannot function.

[0060] It should be noted that, in the embodiments of this application, Figure 1 The system architecture shown is for illustrative purposes only, and there are no restrictions on the deployment methods of each unit.

[0061] The product implementation of this application merges multiple processes into a single process while maintaining the normal operation of the process. The original multiple processes can call each other, and the calls between the original multiple processes will be transformed from IPC calls to function calls (funccall).

[0062] For details, please refer to Figure 2 , Figure 2 A schematic diagram illustrating the implementation of the system service invocation method provided in this application embodiment in the platform software and server hardware. The product implementation can be divided into three steps: before merging, during merging, and after merging, which are described below:

[0063] During the merge preparation, the user process determines the n (n≥1) system service processes it needs for its own operation and allocates a corresponding management structure for the target service to be pulled (one management structure corresponds to one target service process). At the same time, the target information segments (such as target code segments and target data segments) of the system service processes are protected by address isolation to prevent address conflicts with the system service processes after mapping. The link libraries of each system service process are replaced, and the IPC implementation is modified to convert the IPC flow into a function call flow.

[0064] During the merge process, firstly, based on the pre-determined list of system service processes, the address space information of each system service process is read to determine the location of the target code segment, target data segment, and other structures of the system service processes to be merged. Then, the specified segments are sequentially read from the system service processes according to the address information and copied to the pre-allocated address space of the user process. Information about each service being pulled is recorded in the user process for subsequent calls. Next, in the operating system kernel, the virtual address range of the processes needs to be restricted, specifying the range of start and end addresses to prevent address space conflicts after the merge. For stateful service processes, the page fault handling process is modified in the operating system kernel to synchronize the state information to the original system service processes.

[0065] After the merge is complete, the user process can determine the addresses of its functions and data structures based on the address data of the system service processes recorded in the merge and then jump to call them. For calls between two or more mapped system service processes, a dedicated switch function is provided in user space to handle the jump. This function receives the target process and its application programming interface (API) from the service call, performs a table lookup to determine the address for the service process, and then jumps to execute.

[0066] Based on the above system architecture, the following describes the method for invoking the system services provided in the embodiments of this application. Please refer to [link / reference needed] for details. Figure 3 , Figure 3 A flowchart illustrating the method for invoking system services provided in this application embodiment may specifically include the following steps:

[0067] 301. Determine n system service processes based on the first user process, where n≥1.

[0068] First, the computer device determines the n system service processes to be merged based on the current user process (which can be called the first user process).

[0069] It should be noted that this step is performed before process merging. In this step, the first user process needs to determine the user-mode service processes that are frequently called in the critical processing functions, namely the n system service processes. This can be determined by the user analyzing the code of the first user process, or by the computer device directly determining it based on the type of the first user process. This application does not limit this.

[0070] It should be noted that in some embodiments of this application, after determining n system service processes, it is also necessary to perform address isolation (such as SFI) on these n system service processes so that the address space of each system service process is limited to a specified window size. The address isolation process is also performed before process merging. The purpose of address isolation is to ensure that the execution logic of the system service process code only uses the address space within the specified size range, thereby limiting the execution address space of the system service process to the specified size range. This ensures that after the target information segment is copied to the first user process in step 302, there will be no address conflicts with the code of other processes, thus avoiding process crashes.

[0071] It should also be noted that in some embodiments of this application, the link libraries used by each system service process need to be modified to convert the specified IPC implementation into a function call process, so that the original IPC processing flow in the system service process is changed into a function call flow.

[0072] 302. Copy the target information segments of each of the n system service processes to the address spaces of the n preset ranges within the first user process to obtain the second user process. Each system service process corresponds to one preset range of address space.

[0073] Subsequently, the computer device further copies the target information segments of each of the n system service processes determined above to n preset address spaces within the first user process (i.e., a memory space between address a and address b, such as the memory space between addresses 1000 and 5000), resulting in a second user process. Each system service process corresponds to a preset address space. Specifically, the address space information of each system service process is read to determine the location of the target information segments of the system service processes to be merged within the current service process. Then, based on the read address space information, the specified information segments are read from each system service process and copied to the address space pre-allocated by the first user process. The execution process of step 302 is as described above. Figure 2 The merging process corresponding to the embodiment. The n pre-allocated address spaces are pre-allocated by the computer device when the n system service processes are determined in step 301.

[0074] It should be noted that the size of the n preset address spaces can be the same or different, and this application does not limit this.

[0075] As an example, suppose that three system service processes (i.e., n=3) are determined according to step 301, namely process A, process B, and process C. Then the computer device will allocate three preset address spaces within the first user process for these three system service processes. Let's assume these three preset address spaces are address space a (e.g., memory space with addresses 1000-3000), address space b (e.g., memory space with addresses 3001-6000), and address space c (e.g., memory space with addresses 6001-9000). In this example, the address spaces allocated to processes A, B, and C are the same size. In practical applications, the allocated address spaces can also be different. For example, address space a could be memory space with addresses 1000-3000, address space b could be memory space with addresses 3001-7000, and address space c could be memory space with addresses 7001-8000, depending on the actual application scenario. This application does not impose any limitations on this.

[0076] It should be noted that, in some embodiments of this application, in addition to pre-allocating n preset address spaces for these n system service processes, n management units (also called management structures) can also be pre-allocated for these n system service processes, with one management unit corresponding to one system service process. After the computer device copies the target information segments of each of the n system service processes to the n preset address spaces within the first user process, it can further record the status information of each of the n system service processes in the pre-allocated n management units. Each management unit records relevant information about the runtime of each system service process for use in subsequent function calls. This status information can be read when the computer device performs address isolation on each system service process, and then the process merging is completed based on the read information. In this step, the new address information of the target information segments of the merged system service processes is recorded.

[0077] Specifically, in the embodiments of this application, the status information can be at least any of the following: 1) the start address and / or end address of the target information segment corresponding to each system service process in the second user process (i.e., the specific location of the target information segment within the address space allocated to each of them); 2) the data size of the target information segment corresponding to each system service process (i.e., the size of the memory occupied by the target information segment within the address space allocated to each of them); 3) the function and / or function number corresponding to the target information segment corresponding to each system service process (e.g., how many functions correspond to, their respective function names, function numbers, etc.), and a specific function corresponds to the implementation of a function; 4) the value of the register corresponding to each system service process.

[0078] It should be noted that in some embodiments of this application, the target information segment of each copied system service process can be a target code segment (also called a critical code segment), a target data segment (also called a critical data segment), or both. This application does not specifically limit this. The target data segment is the data required by the target code segment during runtime. It is important to note that the target code segment / data segment can be determined by each system service process marking which of its own codes or data are critical code segments / data segments, and then additionally integrating these critical code segments / data segments together for easy copying later when needed.

[0079] It should also be noted that, in some embodiments of this application, the aforementioned n system service processes can be identified within the second user process based on their process IDs. That is, a process ID is pre-assigned to each system service process within the second user process. This process ID serves as a unique identifier for the system service process within the second user process, used to accurately identify and invoke the corresponding system service process in subsequent operations. It should be noted that the process ID is merely an example. In practical applications, a unique code, exclusive number, unique character, or other identification code (ID) can be assigned, as long as it can uniquely identify the corresponding system service process. This application does not impose any limitations on this.

[0080] 303. In the case where the second user process calls the first process, the second user process makes a service call to the first process through a function call. The first process is one of n system service processes.

[0081] Finally, based on the above information, the computer device completes subsequent system service calls through function calls to achieve the desired functionality. This step is executed after the merging process is complete. In this embodiment, the calls can be categorized as follows:

[0082] (1) User process calls system service process.

[0083] This refers to the scenario described above where the second user process calls the first process, where the first process is one of the aforementioned n system service processes. In this case, the service call to the first process is performed within the second user process via a function call. For example, within the second user process, based on the status information recorded in the first management unit (the management unit corresponding to the first process), the service call to the first process is performed via a function call. Specifically, in this step, the address of the function to be called is obtained based on the status information recorded in the second user process's management unit, thereby enabling jump execution.

[0084] (2) System service process calls system service process.

[0085] In other words, when the second process calls the third process, the service call to the third process can be completed through the forwarding function in the second user process. The second process and the third process are any two of the above n system service processes.

[0086] Since each system service process is in an address-isolated state at this time, the mutual calls between the two merged system service processes are completed by the forwarding function in the second user process. This forwarding function receives the process ID and parameters of the target process called by the system service process, and helps the system service process complete the address jump and pass the function return value by accessing the status information recorded in the management unit.

[0087] To facilitate understanding of the above process, a specific example will be used below to illustrate it. Figure 3 The corresponding embodiments are described below; please refer to them for details. Figure 4 , Figure 4 This is a component structure example diagram of the system service invocation method provided in this application embodiment. This example is a case of converting the invocation of a system service process (hereinafter referred to as the target process) for MD5 calculation from an IPC call to a function call. The role of the MD5 service process is to receive a piece of data, calculate the MD5 value of this piece of data, and return the result to the caller. In this application embodiment, the invocation method of this service process is changed from the original IPC call to a function call after merging into the same process. The specific implementation steps are as follows:

[0088] (a) Determine the process ID of the target process and read the address space information of the target process.

[0089] Please refer to details. Figure 5 , Figure 5 The implementation flowchart for step (1) may include the following steps:

[0090] 501. Determine the process ID of the MD5 service process.

[0091] This step first determines the process ID of the MD5 service process.

[0092] 502. Read the address distribution information of the MD5 service process.

[0093] Then, the address distribution (i.e., the location of the target code segment / data segment) is read in the md5 service process as information for the next operation.

[0094] 503. Assign a management unit to the MD5 service process.

[0095] At the same time, the user process allocates the corresponding management unit (i.e., management structure) to the MD5 service process to be pulled.

[0096] (ii) The code of the md5 service process is isolated during the compilation stage, and its link library is modified to change the implementation of specific IPCs.

[0097] Please refer to details. Figure 6 , Figure 6 The implementation flowchart for step (ii) may include the following steps:

[0098] 601. Isolate the address of the MD5 service process.

[0099] First, address isolation is performed on the MD5 service process, such as SFI.

[0100] 602. Record new address distribution information at the location where address distribution information is recorded.

[0101] After isolating the code segment from the MD5 hash, record the new address distribution information of the target code / data segment to be copied at the location where the address distribution information is recorded.

[0102] 603. The MD5 service process has entered hibernation and is awaiting merging.

[0103] The md5 service process has entered a dormant state, awaiting subsequent merging.

[0104] Step (II) ensures process safety after the process merge. After address isolation of the MD5 service process, the memory range used by the MD5 code segment during runtime is limited to a fixed address range. In the subsequent merge, the MD5 service process will be copied to a pre-allocated address space of the user process, ensuring that the execution of the MD5 service process and the original user process do not interfere with each other in terms of address, thus guaranteeing normal process operation. Simultaneously, the link libraries used by the MD5 service process are modified, transforming the specified IPC implementation into a function call flow, thus changing the original IPC processing flow in the MD5 service process to the required function call flow.

[0105] (iii) Copy each code segment / data segment in the md5 service process to the memory space pre-allocated by the user process in sequence.

[0106] Please refer to details. Figure 7 , Figure 7 The implementation flowchart for step (iii) may include the following steps (i.e., performing the following operations sequentially for each address space):

[0107] 701. Allocate address space in user mode.

[0108] First, address space is pre-allocated in user space for the code / data segment to be copied.

[0109] 702. Configure permissions for the newly allocated address space.

[0110] And configure the corresponding permissions for the pre-allocated address space.

[0111] 703. Read data from a specified segment of the MD5 service process.

[0112] Next, it reads data (i.e., a specified segment) from the specified address space of the MD5 service process.

[0113] 704. Copy the data to the user process's pre-allocated address space.

[0114] Finally, the data read from the specified address space is copied to the address space pre-allocated by the user. At the same time, the system kernel restricts the address allocation range of this process in the future, and specifies the starting size of the virtual address to prevent address conflicts when the service process requests memory allocation in the later execution.

[0115] (iv) Record the address range and other information of all merged service processes for subsequent calls.

[0116] Please refer to details. Figure 8 , Figure 8 The implementation flowchart for step (iv) may include the following steps:

[0117] 801. Record address range and other information.

[0118] All memory segment address information is recorded in a series of tables (i.e., management units). The recorded content may include function address information and global variable address information in the original service process function segment and data segment.

[0119] 802. Service calls obtain the target address by looking up a table and then redirect.

[0120] Afterwards, subsequent service calls and calls between system services obtain the target address by looking up a table and then jump to execute.

[0121] (v) Implement the corresponding table lookup and jump functions in the user process to provide service calls and inter-service calls.

[0122] Please refer to details. Figure 9 , Figure 9 The implementation flowchart for step (5) may include the following steps:

[0123] 901. Implement the service redirection function.

[0124] This step implements a dedicated service redirection function.

[0125] 902. When making a service call, push the address of the jump function onto the bottom of the stack for service invocation.

[0126] Before a user process makes a service call, the address of the jump function is pushed onto the bottom of the stack. During service execution, inter-service calls are implemented through the processing function at the bottom of the stack.

[0127] 903. The jump function completes the parameter receiving and table lookup jump operations to realize service calls.

[0128] The processing function finds the address of the target function based on the process ID of the target process and the calling function ID, and then passes the received parameters to the target function to realize the service call.

[0129] Based on the above embodiments, in order to better implement the above solutions of this application, related equipment for implementing the above solutions is also provided below. See details. Figure 10 , Figure 10 This is a schematic diagram of a computer device provided in an embodiment of this application. The computer device 1000 may specifically include: a determining module 1001, a merging module 1002, and a service invocation module 1003. The determining module 1001 is used to determine n system service processes based on a first user process, where n ≥ 1. The merging module 1002 is used to copy the target information segments of each of the n system service processes to n preset address spaces within the first user process to obtain a second user process, where one system service process corresponds to one preset address space. The service invocation module 1003 is used to perform a service invocation on the first process within the second user process by means of a function call when the second user process calls the first process, where the first process is one of the n system service processes.

[0130] In one possible design, the merging module 1002 is further configured to: after copying the target information segments of each of the n system service processes to the address spaces of the n preset ranges within the first user process, record the status information of the n system service processes in the n pre-allocated management units, with one management unit corresponding to one system service process.

[0131] In one possible design, the state information includes at least one of the following:

[0132] The starting and / or ending addresses of the target information segment corresponding to each system service process in the second user process;

[0133] The data size of the target information segment corresponding to each system service process;

[0134] The function and / or function number corresponding to the target information segment of each system service process;

[0135] The value of the register corresponding to each system service process.

[0136] In one possible design, the service invocation module 1003 is specifically used to: within the second user process, make service invocations to the first process through function calls based on the status information recorded in the first management unit, where the first management unit is the management unit corresponding to the first process.

[0137] In one possible design, the determining module 1001 is further configured to: after determining the n system service processes based on the first user process, perform address isolation processing on the n system service processes so that the address space in which each system service process runs is limited to a specified size.

[0138] In one possible design, the determining module 1001 is further configured to: after determining the n system service processes based on the first user process, update the link libraries of the n system service processes and convert inter-process communication (IPC) calls into function calls.

[0139] In one possible design, the determining module 1001 is further configured to: after determining n system service processes based on the first user process, assign a process number to each system service process in the second user process, the process number being used to identify the corresponding system service process.

[0140] In one possible design, the service invocation module 1003 is also used to: in the case of the second process invoking the third process, complete the service invocation of the third process through the forwarding function in the second user process, wherein the second process and the third process are any two processes among the n system service processes.

[0141] In one possible design, the target information segment includes: a target code segment, and / or a target data segment, which contains the data required by the target code segment at runtime.

[0142] It should be noted that the information interaction and execution process between the modules / units in the computer device 1000 are based on the same concept as the method embodiments described above in this application. For details, please refer to the description in the method embodiments shown above in this application, which will not be repeated here.

[0143] Next, we will introduce another computer device provided in the embodiments of this application. Please refer to [link / reference]. Figure 11 , Figure 11 This is a schematic diagram of a computer device provided in an embodiment of this application. The computer device 1100 may be equipped with... Figure 10 The modules of the computer device 1000 described in the corresponding embodiment are used to implement Figure 10 In accordance with the functionality of the computer device 1000 in the corresponding embodiment, specifically, the computer device 1100 is implemented by one or more servers. The computer device 1100 can vary significantly due to differences in configuration or performance, and may include one or more Central Processing Units (CPUs) 1122 and memory 1132, and one or more storage media 1130 (e.g., one or more mass storage devices) for storing application programs 1142 or data 1144. The memory 1132 and storage media 1130 can be temporary or persistent storage. The program stored in the storage media 1130 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the computer device 1100. Furthermore, the CPU 1122 may be configured to communicate with the storage media 1130 and execute the series of instruction operations in the storage media 1130 on the computer device 1100.

[0144] Computer device 1100 may also include one or more power supplies 1126, one or more wired or wireless network interfaces 1150, one or more input / output interfaces 1158, and / or one or more operating systems 1141, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0145] In this embodiment of the application, the central processing unit 1122 is used to execute... Figure 5 or Figure 6The steps performed by the computer device in the corresponding embodiment. For example, the central processing unit 1122 can be used to: determine n system service processes based on the user process, copy the target information segments (such as code segments / data segments) of each of the n system service processes to n preset address spaces within the user process, and when the user process with merged target information segments calls the first process (the first process belongs to the n system service processes), perform a service call on the first process within the user process through a function call.

[0146] It should be noted that the specific way in which the central processing unit 1122 executes the above steps is based on the same concept as the method embodiment of this application, and the technical effects it brings are also the same as those of the above embodiment of this application. For details, please refer to the description in the method embodiment shown above in this application, which will not be repeated here.

[0147] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0148] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0149] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0150] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. 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 transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for invoking a system service, characterized in that, include: Based on the first user process, n system service processes are determined, where n≥1; The target information segments of each of the n system service processes are copied to the address spaces of the n preset ranges within the first user process to obtain the second user process. Each system service process corresponds to one preset range of address space. When the second user process calls the first process, the second user process calls the first process through a function call, and the first process is one of the n system service processes.

2. The method according to claim 1, characterized in that, After copying the target information segments of each of the n system service processes to the address spaces of n preset ranges within the first user process, the method further includes: The status information of the n system service processes is recorded in the n pre-allocated management units, with one management unit corresponding to one system service process.

3. The method according to claim 2, characterized in that, The status information includes at least one of the following: The start and / or end addresses of the target information segment corresponding to each system service process in the second user process; The data size of the target information segment corresponding to each of the system service processes; The function and / or function number corresponding to the target information segment for each system service process; The value of the register corresponding to each of the system service processes.

4. The method according to any one of claims 2-3, characterized in that, The step of making service calls to the first process within the second user process via function calls includes: Within the second user process, the first process is invoked for services through function calls based on the status information recorded in the first management unit. The first management unit is the management unit corresponding to the first process.

5. The method according to any one of claims 1-4, characterized in that, After determining n system service processes based on the first user process, the method further includes: Address isolation is performed on the n system service processes so that the address space in which each system service process runs is limited to a specified size.

6. The method according to any one of claims 1-5, characterized in that, After determining n system service processes based on the first user process, the method further includes: Update the link libraries of the n system service processes to convert inter-process communication (IPC) calls into function calls.

7. The method according to any one of claims 1-6, characterized in that, After determining n system service processes based on the first user process, the method further includes: In the second user process, a process ID is assigned to each of the system service processes, and the process ID is used to identify the corresponding system service process.

8. The method according to any one of claims 1-7, characterized in that, After copying the target information segments of each of the n system service processes to the address spaces of the n preset ranges within the first user process, the method further includes: In the case where the second process calls the third process, the service call to the third process is completed through the forwarding function in the second user process. The second process and the third process are any two processes among the n system service processes.

9. The method according to any one of claims 1-8, characterized in that, The target information segment includes: The target code segment and / or the target data segment, wherein the target data segment is the data required by the target code segment at runtime.

10. A computer device, characterized in that, include: The determination module is used to determine n system service processes based on the first user process, where n≥1; The merging module is used to copy the target information segments of each of the n system service processes to n preset address spaces within the first user process to obtain the second user process, where one system service process corresponds to one preset address space. The service invocation module is used to invoke the service of the first process within the second user process by means of a function call when the second user process invokes the first process. The first process is one of the n system service processes.

11. The device according to claim 10, characterized in that, The merging module is also used for: After copying the target information segments of each of the n system service processes to the address spaces of the n preset ranges within the first user process, the status information of the n system service processes is recorded in the n pre-allocated management units, with one management unit corresponding to one system service process.

12. The device according to claim 11, characterized in that, The status information includes at least one of the following: The start and / or end addresses of the target information segment corresponding to each system service process in the second user process; The data size of the target information segment corresponding to each of the system service processes; The function and / or function number corresponding to the target information segment for each system service process; The value of the register corresponding to each of the system service processes.

13. The device according to any one of claims 11-12, characterized in that, The service invocation module is specifically used for: Within the second user process, the first process is invoked for services through function calls based on the status information recorded in the first management unit. The first management unit is the management unit corresponding to the first process.

14. The device according to any one of claims 10-13, characterized in that, The determining module is further configured to: After determining n system service processes based on the first user process, address isolation is performed on the n system service processes so that the address space in which each system service process runs is limited to a specified size.

15. The device according to any one of claims 10-14, characterized in that, The determining module is further configured to: After determining n system service processes based on the first user process, the link libraries of the n system service processes are updated to convert inter-process communication (IPC) calls into function calls.

16. The device according to any one of claims 10-15, characterized in that, The determining module is further configured to: After determining n system service processes based on the first user process, a process ID is assigned to each system service process in the second user process. The process ID is used to identify the corresponding system service process.

17. The device according to any one of claims 10-16, characterized in that, The service invocation module is also used for: In the case where the second process calls the third process, the service call to the third process is completed through the forwarding function in the second user process. The second process and the third process are any two processes among the n system service processes.

18. The device according to any one of claims 10-17, characterized in that, The target information segment includes: The target code segment and / or the target data segment, wherein the target data segment is the data required by the target code segment at runtime.

19. A computer device comprising a processor and a memory, the processor being coupled to the memory, characterized in that, The memory is used to store programs; The processor is configured to execute a program in the memory, causing the computer device to perform the method as described in any one of claims 1-9.

20. A computer storage medium, characterized in that, The device stores computer-readable instructions, which, when executed by a processor, implement the method as described in any one of claims 1-9.

21. A computer program product, characterized in that, The computer program product includes computer-readable instructions that, when executed by a processor, implement the method as described in any one of claims 1-9.

22. A chip, the chip comprising a processor and a data interface, characterized in that, The processor reads instructions stored in the memory through the data interface and executes the method as described in any one of claims 1-9.

Images