CN113672282B

CN113672282B - Data processing method, device, product and storage medium

Info

Publication number: CN113672282B
Application number: CN202111228417.XA
Authority: CN
Inventors: 吴一昊; 邓二伟; 陈善佩
Original assignee: Alibaba China Co Ltd; Alibaba Cloud Computing Ltd
Current assignee: Alibaba China Co Ltd; Alibaba Cloud Computing Ltd
Priority date: 2021-10-21
Filing date: 2021-10-21
Publication date: 2022-05-31
Anticipated expiration: 2041-10-21
Also published as: CN113672282A

Abstract

The embodiment of the application provides a data processing method, data processing equipment, a product and a storage medium. Wherein the method comprises the following steps: acquiring module configuration information; collecting boundary elements in the kernel source file based on the module configuration information; determining a plurality of objective functions according to the boundary elements; analyzing the categories to which the plurality of objective functions respectively belong; and extracting a target module from the kernel source file according to the types of the boundary elements and the target functions. According to the technical scheme provided by the embodiment of the application, the boundary elements are collected according to the module configuration information and are used as the basis for boundary division, and then the target function is determined according to the boundary elements. According to the boundary element and the target function, the boundary division of the target module is simply and quickly realized, the kernel source file is not influenced in the boundary division process, and the extraction efficiency of the target module can be effectively improved.

Description

Data processing method, device, product and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a data processing method, device, product, and storage medium.

Background

With the development of the Linux application requirements, the user requirements are increasingly diversified, and further, the differentiation requirements of the user on the Linux application system are more and more obvious.

Hot patching (or hot repair, or hot repair patch) is a technique for modifying software defects of a device without affecting the operation of the device. The hot patching technology not only provides a means for timely modifying software errors in the running system, but also can reduce the loss of client income caused by version upgrading. The hot repair is an online repair service facing mobile equipment or a server, provides silent update and fine-grained repair capability for an online version of an application APP or an operating system, helps developers to repair online problems in real time, and releases a lightweight function quickly.

In the existing hot repair technology, a certain subsystem or module in a kernel needs to be updated in a targeted manner sometimes. However, the subsystems or modules in the kernel are mutually staggered, and it is quite difficult to upgrade a certain module or subsystem in the kernel.

Therefore, a technical solution for implementing boundary partition for a certain module or a certain subsystem in a kernel is needed.

Disclosure of Invention

To solve or improve the problems in the prior art, embodiments of the present application provide a data processing method, device, product, and storage medium.

In a first aspect, in one embodiment of the present application, a data processing method is provided. The method comprises the following steps:

acquiring module configuration information;

collecting boundary elements in the kernel source file based on the module configuration information;

determining a plurality of objective functions according to the boundary elements;

analyzing the categories to which the plurality of objective functions respectively belong;

and extracting a target module from the kernel source file according to the types of the boundary elements and the target functions.

In a second aspect, in one embodiment of the present application, there is provided an electronic device comprising a memory and a processor; wherein the content of the first and second substances,

the memory is used for storing programs;

the processor, coupled to the memory, is configured to execute the program stored in the memory, so as to implement the data processing method according to the first aspect.

In a third aspect, in an embodiment of the present application, there is provided a computer product comprising computer programs/instructions which, when executed by a processor, cause the processor to implement a data processing method according to the first aspect.

In a fourth aspect, in one embodiment of the present application, there is provided a non-transitory machine-readable storage medium having stored thereon executable code, which when executed by a processor of an electronic device, causes the processor to perform a data processing method as described in the first aspect.

According to the technical scheme provided by the embodiment of the application, the module configuration information is obtained. And collecting boundary elements in the kernel source file based on the module configuration information. Determining a plurality of objective functions according to the boundary elements. And analyzing the categories to which the plurality of objective functions respectively belong. And extracting a target module from the kernel source file according to the types of the boundary elements and the target functions. By adopting the technical scheme, the boundary elements are collected according to the module configuration information, the boundary elements are used as the basis for boundary division, and then the target function is determined according to the boundary elements. According to the boundary element and the target function, the boundary division of the target module is simply and quickly realized, the kernel source file is not influenced in the boundary division process, and the extraction efficiency of the target module can be effectively improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

Fig. 1 is a schematic flow chart of a data processing method according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a function category analysis method according to an embodiment of the present disclosure;

fig. 3 is a flowchart illustrating a method for determining an external function type according to an embodiment of the present disclosure;

fig. 4 is a schematic flowchart of another external function type determination method according to an embodiment of the present application;

FIG. 5 is a diagram illustrating a process of classifying the categories to which functions belong according to an embodiment of the present application;

fig. 6 is a schematic flowchart of an internal function class determination method according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a target module extraction process illustrated in an embodiment of the present application;

fig. 8 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

When an electronic device (e.g., a server or the like) with a Linux system is maintained, in order to reduce the influence on the operation of the electronic device, a Linux operating system Kernel (or "macro Kernel") is usually maintained by using a hot repair or hot upgrade method. Generally, when performing a hot repair operation, a hot repair is usually performed on a specific module in the core, for example, on the scheduler. However, there is no obvious line of demarcation between the modules or subsystems in the kernel. In the prior art, since a module to be repaired by hot repair involves many functions and parameters, and the types of the functions may include many types, the upgrading work is complicated. For example, a large amount of codes to be modified are required to be modified, a large amount of test review tasks are required to be implemented to solve the problem of conflict caused by code modification, and a large amount of manpower and material resources are required to be consumed to complete the module hot repair task once. Therefore, a technical solution for simply and rapidly implementing kernel module hot repair or upgrade is needed.

In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.

In some of the flows described in the specification, claims, and above-described figures of the present application, a number of operations are included that occur in a particular order, which operations may be performed out of order or in parallel as they occur herein. The sequence numbers of the operations, e.g., 101, 102, etc., are used merely to distinguish between the various operations, and do not represent any order of execution per se. Additionally, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first", "second", etc. in this document are used for distinguishing different messages, devices, modules, etc., and do not represent a sequential order, nor limit the types of "first" and "second" to be different. In addition, the embodiments described below are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Fig. 1 is a schematic flow chart of a data processing method according to an embodiment of the present application. In a practical application scenario, the execution subject of the method may be an electronic device (e.g., a computer, a server, etc.). The method specifically comprises the following steps:

101: module configuration information is obtained.

102: and collecting boundary elements in the kernel source file based on the module configuration information.

103: determining a plurality of objective functions according to the boundary elements.

104: and analyzing the categories to which the plurality of objective functions respectively belong.

105: and extracting a target module from the kernel source file according to the types of the boundary elements and the target functions.

In practical application, modules in the Linux kernel are mutually staggered, for example, in order to meet the calling requirements of various subsystems or modules, the kernel scheduler is provided with a plurality of interface functions for external presentation, and indirect calling between an internal function and an external function is realized through the interface functions. The internal function, the external function, the common data, and the like are contained among the modules to be partitioned. The module configuration information may be determined based on the boundary partitioning requirements of the modules, as desired. These module boundary configuration information may include interface functions, internal functions, external functions, public data, private data, structure members, and the like. When defining the module configuration information, it is necessary to consider that the obtained boundary information corresponding to the target module is easier to maintain, and the boundary can be converged and closed. Easy maintenance as used herein is to be understood as defining only limited interface functions, private data, etc. in the definition of the boundary of the object module, thereby making later maintenance of the object module simpler. The boundary convergence mentioned here can be understood as that interface functions, private data and the like are explicitly specified, so that a clearer standard is provided when boundary division is performed, and even if some functions have staggered complex calling relations, clear boundary division can still be achieved. The closure referred to herein can be understood as that if an external function outside the target module wants to call an internal function inside the target module, the call can be realized only through the interface function or the function pointer, and the interface presented to the outside by the target module is relatively fixed.

It is to be understood that the module configuration information may be specified by a user, and the module configuration information is usually expressed in a high-level language (e.g., assembly, C language, etc.) understood by the user. But the code in the kernel source file is represented by a machine language such as binary. Therefore, after determining the module configuration information, it is further necessary to collect relevant boundary elements from the kernel source files according to the high-level language in the module configuration information, where the boundary elements are codes collected in the kernel source files.

The collection process of the boundary elements is as follows: and compiling the kernel source file based on the module configuration information. Collecting boundary elements corresponding to the module configuration information from the compiled kernel source files; wherein the boundary element comprises: the system comprises an internal function symbol, an external function symbol, a structure member symbol, a private data symbol, a public data symbol, a function call relation, an interface function symbol and a function pointer symbol. It should be noted that the various symbols described herein can be understood as a kernel symbol table, which is a mapping table that is dynamically changeable for a developer to access a corresponding address of a program body through the symbols. In other words, when a developer uses a certain function or variable, the developer only needs to input the corresponding symbol, and does not need to know the address corresponding to the symbol.

For example, using a compiling technique, during compiling a kernel source file, collecting information required for boundary division according to module configuration information, which mainly includes: the name of the symbol, the file where the symbol definition is located (to avoid confusion caused by renaming static symbols), the code section of the symbol definition, the function call relation, the attribute of the symbol (__ init modification and inline modification), the function pointer (including initial value, parameter transfer and assignment, mainly used for interface function), and the interface function. The code interval defined by the symbol is used for determining the corresponding code interval and position when the boundary element is extracted; the function call relationship is used to analyze the category to which the target function belongs in the following embodiments.

It should be noted that, when the function call relationship is extracted, it can be derived from a callgraph view provided by gcc-plugin, where the view provides all the relationships between functions. The function pointer can be obtained by analyzing the abstract syntax tree, and any initial value of the variable is a function and is regarded as the function pointer; the interface function is obtained through module configuration information; other information may be obtained directly from the original symbol information.

Since the module configuration information is much information determined by the user according to the boundary division and the module extraction requirement, some information is to be divided into the target module, and some information is used for assisting in realizing the boundary division. Therefore, after determining the boundary elements, further object function identification needs to be performed according to the boundary elements. The objective function is divided according to the categories, and comprises an internal function and an external function. And through further analysis on the calling relationship between the internal function and the external function, the application range of the structural body and the like, the required target module is accurately extracted from the kernel source file.

In one or more embodiments of the present application, the class to which the objective function belongs includes an internal function and an external function. Extracting a target module from a kernel source file according to the types of the boundary elements and the target functions, wherein the types of the target functions comprise: and extracting a code set from the kernel source file according to the boundary element. And removing the object function with the external category from the code set. Wherein the target module comprises: the code set.

The internal function referred to herein is understood to be defined within the target module and can only be called by internal functions or interface functions. An external function as referred to herein is understood to be defined outside the object module and can be called by an external function and/or an internal function. If a function participates in multiple call paths, as long as the function in any one of the call paths is directly called by an external function, the function is marked as the external function.

As described above, the boundary elements and the plurality of objective functions are extracted from the kernel source files according to the module configuration information. Since some classes of the objective function are not accurately classified when configuring the module configuration information, it can be understood that the classification results of the internal function and the external function are only used as the preliminary internal function set and the preliminary external function set. In order to realize more accurate boundary division, the target function call relationship needs to be further analyzed based on the internal function set and the external function set, and the following embodiment of call relationship analysis will be specifically explained.

In order to enable the finally obtained target module to have better independence and reduce or avoid adverse effects on other modules when the target module is subjected to hot repair or hot upgrade operation, the external function needs to be removed from the target function according to the type of the function. Specifically, after the code set is extracted from the kernel source file based on the boundary elements, the corresponding code of the external function of the data in the code set is removed, so that the code set in the target module is more in line with the requirement of boundary division.

In practical application, the method specifically comprises the following steps of removing an objective function with an external category from the code set: and if the category of the target function is the external function, determining a code interval corresponding to the external function. An external function and the code interval are removed from the code set.

In one or more embodiments of the present application, the module configuration information specifies at least one of: public data, private data, interface functions, function pointers.

Extracting a target module from the kernel source file according to the categories to which the boundary elements and the target functions respectively belong, and the method further comprises the following steps: and if the module configuration information specifies public data, removing the public data from the code set. And if the module configuration information specifies a function pointer, renaming the function pointer. And exporting the interface function in the code set to a header file of the code set. Wherein the target module comprises: the code set and the header file.

As described above, many pieces of information related to the boundary division are specified in the module configuration information in advance. The module configuration information includes public data, private data, interface functions and function pointers. Some of which are partitioned inside the target module and others are considered not to belong to the target module. Specifically, a code set is extracted from a kernel source file based on boundary elements. The content contained in the code set is relatively complicated, some boundary elements are only used for helping to realize boundary division, and the code corresponding to the part of information needs to be removed from the code set. The common data can be understood as that the corresponding symbols are defined outside the target module, the data copy of the common data is not held by the target module, and the original symbols in the kernel can be directly used when the hot upgrade is required.

For example, public data and private data are specified in the module configuration information, the public data defined in the module is further moved out of the module, the variable attribute of the public data is modified by gcc plugin, an external (external) statement is added, and the line of source code is directly replaced.

As another example, a function pointer is specified in the module configuration information. And renaming the function pointer in the module. The function pointer renaming is carried out to ensure that the function head before the original renaming is always executed first, and then the function after the renaming of the current module is skipped. The reason is that the functions that are function pointers do not know when they will be called, and if renaming is not used and the original function header is preserved, the atomicity of hot upgrades is destroyed. In the actual renaming process, gcc-plugin can be used to conveniently modify the function name of the function pointer, and generate a function declaration, for example, the void function (int x) { } function is automatically modified as follows:

extern void function(int x);

void __mod_function(int x){}

in one or more embodiments of the present application, in order to facilitate management of the target modules and development and utilization of the target modules by subsequent developers, a directory of one target module may be generated according to the target modules. Specifically, a catalog corresponding to the target module is generated according to the categories to which the boundary elements and the target functions respectively belong.

In practical application, in order to facilitate the development of the target module by subsequent developers and avoid the random modification of boundary related parameters (such as interface function call relation, private data attribute and the like) in the target module by the developers, the module related functions extracted from the kernel source file are stored in a directory. That is, in the development work of the target module by the developer, when a certain function needs to be called, only the function needed by the function can be called and further developed from the directory, and the developer is not allowed to add a new function in the directory. Because it is considered that the target module developer may only be responsible for a certain subsystem or a certain module, but does not know the association relationship between the interface function and other subsystems in certain boundary information, the developer can quickly find the function required by the developer through the directory. In addition, the stability of the target module can be effectively prevented from being threatened by developers to add and delete the interface function.

As previously described, external functions and common data that do not belong within the mine need to be removed from the corresponding code set of the kernel source file in the target module. The boundary element includes a symbol corresponding to public data, a symbol corresponding to private data, and the like, and it is known from the above embodiments that the public data does not belong to the target module. Therefore, when generating a directory, it is necessary to generate a corresponding directory according to an actually valid target module. After the boundary partition directory is generated, the boundary partition directory needs to be compiled in combination with hot upgrade support codes.

In one or more embodiments of the present application, when the module configuration information includes a member of a structure, the method further includes:

determining internal structural body members which cannot be called outside the target module and external structural body members which can be called outside the target module according to the calling range of the structural body members;

generating a structure boundary document based on the inner structure member and the outer structure member;

wherein the target module comprises: the code set, the header file and the structure boundary document.

In practical application, the structure members are divided according to the callable range, and can be divided into inner structure members and outer structure members. The structural members that can be called across the boundary are referred to as external structural members, and the structural members that are only applied to the inside of the module are referred to as internal structural members.

After determining the internal structure members and the external structure members, the structure member boundary documents may be obtained based on the kernel source files, or may be configured by the user. The structure member boundary document may be exposed to developers, but only allow subsequent developers to modify the internal structure members. And then, based on the previously extracted target module correlation function and the newly acquired structural body member boundary document. The directory includes a code set, a header file and a structure boundary document, and the code set and the structure member information corresponding to the function in the target module, the storage path information and the corresponding directory name can be seen. In turn, the catalog is stored into the code repository of the kernel.

In one or more embodiments of the present application, fig. 2 is a schematic flowchart of a function category analysis method provided in the embodiments of the present application. As can be seen from fig. 2, the analyzing the categories to which the plurality of objective functions respectively belong includes the following steps: 201: and acquiring the function call relations of the plurality of target functions in the compiling process of the kernel source file. 202: and determining a calling path associated with each target function in the plurality of target functions according to the calling relationship. 203: and determining the categories of the target functions according to the analysis result of the calling path.

The function call relation referred to herein may be acquired at the time of boundary element extraction based on the module configuration information. After the module configuration information is determined, if the relevant boundary elements in the kernel source file are to be acquired, the kernel source file needs to be acquired in the compiling process. In addition to being able to obtain the boundary element, a plurality of function call relationships related to the module configuration information can also be obtained. It should be noted that the same function may participate in multiple call paths at the same time, in other words, when a call path corresponding to a certain external function is found based on the call relationship of the external function, multiple call paths can be found. Some of the call paths may include external functions, internal functions, and interface functions specified by the module configuration information; in other call paths, the external function and the internal function specified by the module configuration information may be included, and the interface function is not included, that is, the internal function may be directly called by the external function.

Further, referring to fig. 3, a specific method for analyzing the function type according to the call path in step 203 is shown. Fig. 3 is a schematic flowchart of a method for determining an external function category according to an embodiment of the present disclosure. From fig. 3 it can be seen that the following steps are included:

301: determining a plurality of functions in the calling path, wherein the functions have calling relations with the target functions.

302: and if the plurality of functions do not comprise the interface function, determining that the target function in the calling path is an external function.

303: an updated set of external functions is generated that includes the target function marked as an external function.

It should be noted that the module configuration information specifies an internal function set and an external function set.

According to the internal function set and the external function set specified in the module configuration information, the category of each corresponding function in the target function can be preliminarily known. As explained in the above embodiments, the internal function set and the external function set specified in the module configuration information are not very accurate, and are usually specified by a worker according to experience, however, the calling relationship in the actual function calling process is very complex, and the number of involved functions is also large, and it is difficult for the worker to completely distinguish the categories of all the functions. Therefore, it is necessary to perform further analysis and determination work of the category to which the function belongs on the basis of the internal function set and the external function set obtained by the above approximate classification.

In particular, the class of a function will be determined according to whether there is a direct call between an internal function and an external function in the call path. If the internal function has any associated calling path and has the condition of being directly called by the external function, the internal function is divided into the external function set again, so that the updated external function set is obtained. By the classification of the function category, the condition that any function classified into the target module affects other modules or subsystems outside the target module can be effectively avoided.

Fig. 4 is a schematic flowchart of another external function class determination method according to an embodiment of the present application. If the plurality of functions do not include the interface function, determining that the target function in the call path is an external function, including the following steps:

401: if any internal function in the internal function set is contained in the target functions and the interface function is not contained in the target functions, marking the internal function as an external function;

402: assigning the any internal function from the internal function set to the updated external function set.

For ease of understanding, the following will be specifically exemplified. Fig. 5 is a schematic diagram illustrating a process of classifying a class to which a function belongs according to an embodiment of the present application. As can be seen from fig. 5, the internal function 1 and the internal function 2 are included in the internal function set, and the external function 1 and the external function 2 are included in the external function set. When a function call is made, it can be seen that, in the call path 1, the external function 1 indirectly calls the internal function 1 through the interface function 1. In the call path 2, the external function 2 is called directly when calling the internal function 2. In the calling path 3, the external function 3 calls the internal function 3 through the interface function 2; in the call path 4, the external function 4 directly calls the internal function 3.

Next, a detailed analysis is performed based on fig. 4. As can be seen from fig. 5, although the internal function 2 in the call path 2 is initially divided into internal functions, it is found by analysis that the internal function 2 is directly called by the external function 2, and therefore, it is necessary to change the category to which the internal function 2 belongs, change the category to the external function, and divide the external function into updated external function sets. The internal function 3 is divided into internal functions, the external function 3 calls the internal function 3 through the interface function 2 in the calling path 3, but the external function 4 directly calls the internal function 3 in the calling path 4; therefore, it is necessary to change the category of the internal function 3, change it into an external function, and divide it into the updated external function set. There is only one call path for the internal function 1, and the external function 1 calls the internal function 1 through the interface function 1, so the internal function 1 is kept in the original internal function set through analysis. The function originally divided into the internal function set can be corrected through the embodiment, and therefore, the function which is not divided into the internal function set by mistake can be ensured to be divided into the internal function set.

Fig. 6 is a schematic flowchart of an internal function type determining method according to an embodiment of the present application. As can be seen from fig. 6, the determining the categories to which the plurality of target functions respectively belong according to the analysis result of the call path includes the following steps:

601: and determining a function set corresponding to the plurality of target functions.

602: and removing the updated external function set, the interface function and the function pointer based on the function set.

603: and generating an updated internal function set.

Based on the embodiments shown in fig. 3 to 5, the updated external function set can be accurately determined. Based on the module configuration information and the updated external function set, a function set containing all the objective functions can be obtained. The function set includes an internal function, an external function, an interface function, and a function pointer. Since the interface functions and function pointers are specified accurately in the module configuration information, no changes or changes need to occur. And the external function has obtained a more perfect updated set of external functions through the embodiments corresponding to fig. 3 to 5. Therefore, it is possible to further remove the updated external function set, the interface function, and the function pointer that can be determined from the function set, and the rest is the updated internal function set. This set of internal functions is an exact set in that there is no direct call to any one internal function by an external function. Therefore, boundary division of the target module and operability of hot upgrade are also ensured.

In order to facilitate understanding of the technical solution of the present application, an extraction process of the target module will be described below with reference to a specific embodiment. Fig. 7 is a schematic diagram of an object module extraction process illustrated in the embodiment of the present application. As can be seen from fig. 7, according to the actual requirement for boundary partitioning of the target module, the kernel source file of the module, the interface function and private data of the module, and the like are determined, and then the module configuration information is generated based on these basic information. Then, the collection of information such as boundary elements is realized in the process of compiling the kernel source file. These boundary elements include various symbols (e.g., internal function symbols, external function symbols, interface function symbols, etc.). It is easy to understand that although the module configuration information specifies the internal function and the external function, since there are many functions in the module, it is impossible to accurately distinguish which functions are internal functions and which functions are external functions, and therefore, further boundary analysis is required. After the boundary analysis, an internal function and an external function can be accurately obtained, and a boundary configuration document is generated by combining the interface function, the function pointer, the private data and the like determined before. Boundary extraction is performed from the kernel source file based on the boundary configuration document. The extraction process simply comprises: external function removal, common data exception, function pointer renaming, function export (exporting declaration of interface function and function pointer into header file), structure member boundary division and the like. And after the boundary information extraction work is completed, generating a target module. By analyzing the boundary division requirement, the interface function is accurately determined, and the boundary information is corrected based on the interface function to obtain the boundary division document, so that the boundary division processing efficiency and the boundary division accuracy can be effectively improved. After the target module is obtained, complex operations such as rapid hot upgrade of the target module can be achieved.

Based on the same idea, the embodiment of the application further provides a data processing device. Fig. 8 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application. The data processing apparatus includes:

and an obtaining module 81, configured to obtain module configuration information.

A collecting module 82, configured to collect boundary elements in the kernel source file based on the module configuration information.

A determining module 83, configured to determine a plurality of objective functions according to the boundary elements.

And the analysis module 84 is configured to analyze categories to which the plurality of objective functions respectively belong.

And the extracting module 85 is configured to extract a target module from the kernel source file according to the category to which the boundary element and the target functions respectively belong.

Optionally, the class to which the objective function belongs includes an internal function and an external function. An extracting module 85, configured to extract a code set from the kernel source file according to the boundary element; removing the object function which belongs to the category of the external object function from the code set; wherein the target module comprises: the code set.

Optionally, at least one of the following is specified in the module configuration information: public data, private data, interface functions, function pointers. An extracting module 85, configured to, if public data is specified in the module configuration information, remove the public data from the code set; if the module configuration information designates a function pointer, renaming the function pointer; exporting the interface functions in the code set to a header file of the code set; wherein the target module comprises: the code set and the header file.

Optionally, the method further includes a generating module 86, configured to generate a directory corresponding to the target module according to the category to which the boundary element and the target function belong respectively.

Optionally, when the module configuration information includes a structural body member, the generating module 86 is further configured to determine, according to a calling range of the structural body member, an internal structural body member that cannot be called outside the target module and an external structural body member that can be called outside the target module; generating a structure boundary document based on the inner structure member and the outer structure member; wherein the target module comprises: the code set, the header file and the structure boundary document.

Optionally, the analysis module 84 is configured to obtain function call relationships of the multiple target functions in the process of compiling the kernel source file; determining a calling path associated with each target function in the plurality of target functions according to the calling relationship; and determining the categories of the target functions according to the analysis result of the calling path.

Optionally, the module configuration information specifies an internal function set and an external function set. A determining module 83, configured to determine a plurality of functions in the call path, where the functions have call relationships with the target functions; if the plurality of functions do not comprise the interface function, determining that a target function in the calling path is an external function; an updated set of external functions is generated that includes the target function marked as an external function.

Optionally, the determining module 83 is further configured to mark any internal function as an external function if the plurality of objective functions include any internal function in the internal function set and the plurality of functions do not include the interface function; assigning the any internal function from the internal function set to the updated external function set.

Optionally, the determining module 83 is further configured to determine a function set corresponding to the plurality of objective functions; removing the updated external function set, the interface function and the function pointer based on the function set; and generating an updated internal function set.

Optionally, the system further includes a removing module 87, configured to determine a code interval corresponding to the external function if the class of the target function is the external function; an external function and the code interval are removed from the code set.

Optionally, the collection module 82 is configured to compile the kernel source file based on the module configuration information; collecting boundary elements corresponding to the module configuration information from the compiled kernel source files; wherein the boundary element comprises: the system comprises an internal function symbol, an external function symbol, a structure member symbol, a private data symbol, a public data symbol, a function call relation, an interface function symbol and a function pointer symbol.

An embodiment of the application also provides an electronic device. Fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application. The electronic device comprises a memory 901, a processor 902 and a communication component 903; wherein the content of the first and second substances,

the memory 901 is used for storing programs;

the processor 902, coupled to the memory, is configured to execute the program stored in the memory to:

acquiring module configuration information;

The memory 901 described above may be configured to store other various data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device. The memory may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

Further, the processor 902 in this embodiment may specifically be: and the programmable exchange processing chip is provided with a data copying engine and can copy the received data.

When the processor 902 executes the program in the memory, other functions may be implemented in addition to the above functions, which may be specifically referred to in the description of the foregoing embodiments. Further, as shown in fig. 9, the electronic device further includes: display component 904, and the like.

Based on the same idea, embodiments of the present application further provide a computer product, which includes a computer program/instruction, and when the computer program/instruction is executed by a processor, the processor is enabled to implement the steps in fig. 1 to fig. 6.

Based on the same idea, embodiments of the present application further provide a non-transitory machine-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the steps as in fig. 1 to 6.

Based on the above embodiment, module configuration information is obtained. And collecting boundary elements in the kernel source file based on the module configuration information. Determining a plurality of objective functions according to the boundary elements. And analyzing the categories to which the plurality of objective functions respectively belong. And extracting a target module from the kernel source file according to the types of the boundary elements and the target functions. By adopting the technical scheme, the boundary elements are collected according to the module configuration information, the boundary elements are used as the basis for boundary division, and then the target function is determined according to the boundary elements. According to the boundary element and the target function, the boundary division of the target module is simply and quickly realized, the kernel source file is not influenced in the boundary division process, and the extraction efficiency of the target module can be effectively improved.

The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.

Claims

1. A method of data processing, comprising:

acquiring module configuration information; at least one of the following is specified in the module configuration information: public data, private data, interface functions, and function pointers;

collecting boundary elements in a kernel source file based on the module configuration information;

and extracting a target module from the kernel source file according to the categories to which the boundary elements and the target functions respectively belong.

2. The method of claim 1, the class of the objective function comprising an internal function and an external function;

extracting a target module from the kernel source file according to the categories to which the boundary elements and the target functions respectively belong, wherein the method comprises the following steps:

extracting a code set from a kernel source file according to the boundary element;

removing the object function which belongs to the category of the external object function from the code set;

wherein the target module comprises: the code set.

3. The method of claim 2, wherein at least one of the following is specified in the module configuration information: public data, private data, interface functions, and function pointers;

extracting a target module from the kernel source file according to the categories to which the boundary elements and the target functions respectively belong, and further comprising:

if public data is specified in the module configuration information, removing the public data from the code set;

if the module configuration information designates a function pointer, renaming the function pointer;

exporting the interface functions in the code set to a header file of the code set;

wherein the target module comprises: the code set and the header file.

4. The method of claim 1, further comprising:

and generating a catalog corresponding to the target module according to the categories to which the boundary elements and the target functions respectively belong.

5. The method of claim 3, wherein when the module configuration information further includes structural body members, the method further comprises:

6. The method of claim 5, the analyzing the respective categories to which the plurality of objective functions belong, comprising:

in the process of compiling the kernel source file, acquiring function call relations of the plurality of target functions;

determining a calling path associated with each target function in the plurality of target functions according to the calling relationship;

and determining the categories of the target functions according to the analysis result of the calling path.

7. The method of claim 6, wherein the module configuration information specifies a set of internal functions and a set of external functions;

determining the categories to which the plurality of target functions respectively belong according to the analysis result of the call path, wherein the determining comprises the following steps:

determining a plurality of functions in the calling path, wherein the functions have calling relations with the target functions;

if the plurality of functions do not comprise the interface function, determining that a target function in the calling path is an external function;

an updated set of external functions is generated that includes the target function marked as an external function.

8. The method of claim 7, wherein determining that a target function in the call path is an external function if the interface function is not included in the plurality of functions comprises:

if the target functions comprise any internal function in the internal function set and the functions do not comprise the interface function, marking the internal function as an external function;

assigning the any internal function from the internal function set to the updated external function set.

9. The method of claim 8, wherein the determining the categories to which the target functions respectively belong according to the analysis result of the call path comprises:

determining a function set corresponding to the plurality of target functions;

removing the updated external function set, the interface function and the function pointer based on the function set;

and generating an updated internal function set.

10. The method of claim 2, said removing from the code set an objective function that belongs to the class of external, comprising:

if the category of the target function is an external function, determining a code interval corresponding to the external function;

an external function and the code interval are removed from the code set.

11. The method of claim 1, the collecting boundary elements in kernel source files based on the module configuration information, comprising:

compiling the kernel source file based on the module configuration information;

collecting boundary elements corresponding to the module configuration information from the compiled kernel source files; wherein the boundary element comprises: the system comprises an internal function symbol, an external function symbol, a structure member symbol, a private data symbol, a public data symbol, a function call relation, an interface function symbol and a function pointer symbol.

12. An electronic device comprising a memory and a processor; wherein the content of the first and second substances,

the memory is used for storing programs;

the processor, coupled with the memory, is configured to execute the program stored in the memory for implementing the method of any of the preceding claims 1 to 11.

13. A non-transitory machine-readable storage medium having stored thereon executable code, which when executed by a processor of an electronic device, causes the processor to perform the steps of any of the methods of claims 1-11.