Resource configuration method and device of kernel system, computer equipment and storage medium

Abstract

The invention relates to the technical field of computers, and discloses a resource configuration method and device for a kernel system, computer equipment and a storage medium, and the method comprises the steps: obtaining Buildroot extension resources configured by a user for the kernel system; reading a target resource type and resource description information of the Buildroot extension resource; an auxiliary construction script deployed in a Buildroot directory is started, and resource configuration strategies corresponding to different resource types are configured in the auxiliary construction script; and calling the auxiliary construction script to determine a target resource configuration strategy corresponding to the target resource type, and performing resource configuration according to the target resource configuration strategy and the resource description information. The problem that manual configuration operation is needed in the mirror image construction process in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a resource configuration method, device, computer equipment and storage medium of a kernel system. Background Art

[0002] In the field of embedded development, it is common practice to customize specific Linux distributions, which includes customizing bootloaders, kernels, and file systems according to product functions and features. The traditional manual image building method is not only slow, but also requires high technical skills of the builder, and the built image is usually only suitable for specific embedded devices. In order to solve these problems, various build tools such as Buildroot have emerged, which can automatically build a complete Linux system for embedded systems, including cross-compilation toolchain, root file system, Linux kernel image, and bootloader.

[0003] However, the existing Buildroot tool still has some operations that require manual configuration by the user during the image building process, such as adapting to new development boards, adding / changing patch files, and adding application software tools. These manual configuration operations not only have the risk of path modification errors, but also increase the redundancy of the build steps, affect the user experience, and reduce the flexibility of the build method. In particular, when it is necessary to integrate third-party application tools other than Buildroot or self-developed application software tools, manual configuration operations are more cumbersome. Summary of the invention

[0004] In view of this, the embodiments of the present invention provide a resource configuration method, apparatus, computer equipment and storage medium for a kernel system to solve the problem of manual configuration operation required in the image building process in the prior art.

[0005] In a first aspect, an embodiment of the present invention provides a resource configuration method for a kernel system, the method comprising:

[0006] Get the user's Buildroot extension resources for kernel system configuration;

[0007] Read the target resource type and resource description information of the Buildroot extension resource;

[0008] Start the auxiliary build script deployed in the Buildroot directory, wherein the auxiliary build script is configured with resource configuration strategies corresponding to different resource types;

[0009] The auxiliary construction script is called to determine the target resource configuration policy corresponding to the target resource type, and resource configuration is performed according to the target resource configuration policy and the resource description information.

[0010] Further, the reading of the target resource type and resource description information of the Buildroot extension resource includes:

[0011] Traverse the directory where the Buildroot extension resource is located to obtain resource identification information corresponding to the Buildroot extension resource;

[0012] Query whether there is a resource type corresponding to the resource identification information;

[0013] If the resource type corresponding to the resource identification information exists, taking the resource type corresponding to the resource identification information as the target resource type;

[0014] Based on the association relationship between the resource type and the preset description information, the resource description information associated with the target resource type is read from the directory where the Buildroot extension resource is located.

[0015] Furthermore, the method further comprises:

[0016] If the resource type corresponding to the resource identification information does not exist, displaying a resource type list based on the display interface, wherein the resource type list includes multiple resource types;

[0017] detecting a selection operation acting on the list of resource types;

[0018] In response to the selection operation, the resource type selected in the resource type list is used as the target resource type.

[0019] Further, the calling of the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and performing resource configuration according to the target resource configuration policy and the resource description information, includes:

[0020] If the target resource type is a new patch file type, the development board name, patch file name, and new patch file path are extracted from the resource description information;

[0021] Search the corresponding patch file in the preset storage location according to the patch file name, and determine the target directory where the patch file is copied according to the development board name;

[0022] Call the auxiliary build script to automatically copy the found patch file to the target directory and obtain the file location of the target board configuration file;

[0023] Read the file content of the target board configuration file based on the file location;

[0024] Searching the original patch file path in the file content;

[0025] The auxiliary construction script is called to add the newly added patch file path to the original patch file path, and then the modified configuration file content is rewritten into the configuration file to complete the update of the configuration file.

[0026] Further, the calling of the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and performing resource configuration according to the target resource configuration policy and the resource description information, includes:

[0027] If the target resource type is to add a third-party application software tool type, then extract the software package name and the configuration file path from the resource description information;

[0028] Call the auxiliary build script to create a configuration file in the Buildroot directory according to the software package name;

[0029] The package configuration file path is added to the configuration file, and a prompt message is output to the user to prompt the user to edit the configuration file created by the script.

[0030] Further, the calling of the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and performing resource configuration according to the target resource configuration policy and the resource description information, includes:

[0031] If the target resource type is a build target board type, the target board name is extracted from the resource description information;

[0032] According to the target board name, search for the corresponding default configuration file in the preset storage location;

[0033] The auxiliary construction script is called to read the file content of the default configuration file, obtain configuration parameters, and automatically perform configuration operations of the target board according to the configuration parameters.

[0034] Furthermore, after performing resource configuration according to the target resource configuration strategy and the resource description information, the method further includes:

[0035] Obtaining a resource configuration result, wherein the resource configuration result is obtained by the auxiliary construction script performing resource configuration according to the target resource configuration strategy and the resource description information;

[0036] If the resource configuration result shows an abnormality, obtaining a log file during the resource configuration process;

[0037] Parse the log file to obtain the target reason and target file of the abnormal display of the resource configuration result;

[0038] Obtaining a processing strategy corresponding to the target cause from a preset strategy library, and processing the target file according to the processing strategy to obtain a processed target file;

[0039] Re-execute the resource configuration operation using the processed target file.

[0040] In a second aspect, an embodiment of the present invention provides a resource configuration device for a kernel system, the device comprising:

[0041] The acquisition module is used to obtain the user's Buildroot extension resources for kernel system configuration;

[0042] A reading module, used to read the target resource type and resource description information of the Buildroot extension resource;

[0043] A startup module is used to start the auxiliary build script deployed in the Buildroot directory, wherein the auxiliary build script is configured with resource configuration strategies corresponding to different resource types;

[0044] The calling module is used to call the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and perform resource configuration according to the target resource configuration policy and the resource description information.

[0045] In a third aspect, an embodiment of the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0046] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method of the first aspect or any corresponding embodiment thereof.

[0047] The method provided in the embodiment of the present application has the following beneficial effects:

[0048] The method provided in this embodiment obtains the Buildroot extension resource configured by the user for the kernel system, and reads the target type and description information of the resource. The present invention can automatically call the auxiliary construction script, perform resource configuration according to the configuration policy corresponding to the resource type, reduce manual configuration operations, reduce the risk of path modification errors, and improve construction efficiency and user experience. The present invention supports the automated configuration of multiple resource types, including adding patch files, adding third-party application software tools, and building target boards. Through flexible configuration strategies, the present invention can adapt to different embedded development requirements and improve the flexibility and applicability of construction. In the resource configuration process, the present invention also provides an exception handling mechanism. When the resource configuration result shows an exception, the log file can be automatically obtained, the cause of the exception and the target file can be parsed, and the processing strategy can be obtained from the preset policy library for processing. This ensures the accuracy and stability of resource configuration. The present invention not only provides a solution at the method level, but also further provides a resource configuration device, a computer device, and a computer-readable storage medium for the kernel system. This enables the present invention to be widely promoted and used in practical applications, providing strong technical support for the field of embedded development. In summary, the resource configuration method of the kernel system provided in this embodiment effectively solves the problem of manual configuration operation required in the image building process in the prior art through automated configuration, enhanced flexibility, exception handling mechanism and a comprehensive support system, and brings significant technological progress and practical application value to the field of embedded development. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0050] Figure 1 is a schematic flow chart of a resource configuration method of a kernel system according to an embodiment of the present invention;

[0051] Figure 2 is a schematic diagram of a process for building Buildroot according to an embodiment of the present invention;

[0052] Figure 3 is a schematic diagram of a process of adding a kernel patch file according to an embodiment of the present invention;

[0053] Figure 4 is a schematic diagram of a process of adding a third-party application software tool according to an embodiment of the present invention;

[0054] Figure 5is a structural block diagram of a resource configuration device of a kernel system according to an embodiment of the present invention;

[0055] Figure 6 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0057] According to an embodiment of the present invention, an embodiment of a resource configuration method for a kernel system is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0058] In this embodiment, a kernel system resource configuration method is provided. Figure 1 is a flow chart of a resource configuration method of a kernel system according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0059] Step S11, obtaining the Buildroot extension resources configured by the user for the kernel system.

[0060] In an embodiment of the present application, the user needs to provide Buildroot extension resources for the kernel system configuration, such as kernel patches, third-party or self-developed software tools. These resources can be input through command lines, graphical interfaces, or configuration files. Receive and store these resources, including file upload, download, parsing, and storage. After receiving, the integrity and correctness of the resources need to be verified, such as checking the file format, size, and content. The verified resources are organized in a directory structure and passed to subsequent steps for processing, such as calling scripts, tools, or commands, and using the resources as input parameters.

[0061] Step S12, reading the target resource type and resource description information of the Buildroot extended resource.

[0062] In the embodiment of the present application, reading the target resource type and resource description information of the Buildroot extension resource includes the following steps A1-A4:

[0063] Step A1, traverse the directory where the Buildroot extension resource is located, and obtain resource identification information corresponding to the Buildroot extension resource.

[0064] Specifically, first determine the location of the Buildroot extension resource directory. The path can be obtained through the configuration file or user input. Then use Python's os.walk function to traverse the directory. During the traversal process, for each file, record its file name and file path. To determine the file type, you can check the file name extension. Store these file name, file path, file type, file size and other identification information in a suitable data structure. For example, a list can be stored in the form of [file name, file path, file type, file size]; a dictionary can use the file path as the key to store the corresponding file name, type, size and other information; or you can create a custom data class to encapsulate this information. After obtaining the resource identification information, pass it to the subsequent steps to perform operations such as resource type query, description information reading and resource configuration.

[0065] Step A2: Check whether there is a resource type corresponding to the resource identification information.

[0066] Specifically, by analyzing the file type part in the resource identification information, it is queried whether the corresponding resource type exists. For known file extensions, such as .patch corresponding to the kernel patch file type, it can be directly judged. For files with unknown extensions, you can try to determine their type by reading the specific byte sequence of the file or using some file type identification libraries. At the same time, the file size can be used as an auxiliary identifier and obtained through the os.path.getsize function. For example, if the size of a file is abnormally small or large, it means that the file is incomplete or the type judgment is incorrect. If it can be determined through these methods that the file corresponding to the resource identification information belongs to one of the known resource types, then it is considered that the corresponding resource type exists.

[0067] Step A3: If there is a resource type corresponding to the resource identification information, the resource type corresponding to the resource identification information is used as the target resource type.

[0068] Specifically, if it is determined that there is a resource type corresponding to the resource identification information, then this resource type is used as the target resource type. For example, if a file is determined to be a kernel patch file type, then the kernel patch file type is used as the target resource type of this file. The target resource type will be used for further processing in subsequent steps, such as adopting different resource configuration strategies according to different resource types.

[0069] Step A4, based on the association relationship between the resource type and the preset description information, read the resource description information associated with the target resource type from the directory where the Buildroot extension resource is located.

[0070] Specifically, an association relationship between resource types and preset description information is established in advance. For example, the kernel patch file type is associated with description information about the function of the patch, the applicable development board, etc. When the target resource type is determined, the resource description information related to the target resource type is searched in the directory where the Buildroot extension resource is located according to this association relationship. This description information can be obtained by reading a specific configuration file or database. This description information will provide more detailed guidance for subsequent resource configuration, such as determining which development board the patch should be applied to and how to configure it according to the description information of the patch.

[0071] In the embodiment of the present application, the method further includes the following steps B1-B3:

[0072] Step B1: If there is no resource type corresponding to the resource identification information, a resource type list is displayed based on a display interface, wherein the resource type list includes a plurality of resource types.

[0073] Specifically, if it is determined that there is no resource type corresponding to the resource identification information, a resource type list is displayed based on the display interface. This list contains multiple predefined resource types, such as kernel patch file types, third-party application software tool types, self-developed tool types, etc. The display interface can be a graphical user interface (GUI), which presents this list in the form of a pop-up window, a drop-down menu, or a special resource type selection window, so that the user can intuitively see the various optional resource types.

[0074] Step B2: detecting a selection operation on the resource type list.

[0075] Specifically, the user's operations on the resource type list are continuously detected. When the user interacts with the resource type list on the display interface, these operations are captured in real time. For example, the user selects a resource type in the list by mouse click, keyboard input, or touch.

[0076] Step B3, in response to the selection operation, the resource type selected in the resource type list is used as the target resource type.

[0077] Specifically, after detecting the user's selection operation, respond immediately and determine the resource type selected by the user in the resource type list as the target resource type. This target resource type will be passed to subsequent processing steps, just like the target resource type determined in step A3, for further operations such as resource description information reading and resource configuration.

[0078] Step S13, starting the auxiliary build script deployed in the Buildroot directory, wherein the auxiliary build script is configured with resource configuration policies corresponding to different resource types.

[0079] In an embodiment of the present application, after determining the target resource type, the auxiliary build script deployed in the Buildroot directory is started. The auxiliary build script is configured with resource configuration policies corresponding to different resource types during design. When the script is started, it will automatically select and execute the corresponding resource configuration policy based on the target resource type passed in. For example, if the target resource type is a kernel patch file type, the script will be ready to execute the configuration policy related to the kernel patch file; if it is a third-party application software tool type, the script will switch to the corresponding configuration policy. Deployment in the Buildroot directory can easily interact and integrate with the Buildroot build process, ensuring that resource configuration can be smoothly integrated into the entire image building process. Such a design enables the system to flexibly configure resources according to different resource types, improving the automation and scalability of image building.

[0080] Step S14, calling the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and performing resource configuration according to the target resource configuration policy and resource description information.

[0081] It should be noted that the target resource types include kernel patch file types, third-party application software tool types, self-developed tool types, and build target board types. There are different target resource configuration strategies that match the above target resource types. Buildroot build process, such as Figure 2 As shown, it includes: selecting the required software packages, kernel configurations and other build parameters through the configuration interface (such as the makemenuconfig interface); in the Buildroot configuration, adding and managing open source components and self-developed components, such as libraries, tools, drivers, etc., according to user needs; after the configuration is completed, the embedded Linux build tool Buildroot integrates and manages the components to ensure collaborative work; Buildroot automatically downloads source code, processes dependencies, compiles software, and generates multiple file systems based on the configuration and components. Each file system contains all the libraries, tools, configuration files, etc. required for the embedded system.

[0082] In the embodiment of the present application, calling the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and performing resource configuration according to the target resource configuration policy and resource description information, includes the following steps C1-C6:

[0083] Step C1: if the target resource type is a newly added patch file type, extract the development board name, patch file name and newly added patch file path from the resource description information.

[0084] Specifically, if the target resource type is determined to be a newly added patch file type, an extraction operation is performed from the resource description information. First, the development board name is extracted. This name will determine the target development board to which the patch file is ultimately applied. Through the development board name, the corresponding configuration information and target directory can be queried. Next, the patch file name is extracted. This name is used to accurately locate the patch file in the preset storage location in subsequent steps. Finally, the path of the newly added patch file is extracted. This path information indicates the specific storage location of the patch file in the system, providing a key basis for subsequent copy operations.

[0085] Step C2, searching for the corresponding patch file in a preset storage location according to the patch file name, and determining the target directory to which the patch file is copied according to the development board name.

[0086] Specifically, according to the name of the extracted patch file, a search is performed in the preset storage location. The preset storage location can be a specific directory or database, in which various patch files are stored. By searching by the patch file name, the corresponding patch file can be found quickly and accurately. At the same time, the target directory to which the patch file is copied is determined according to the development board name. This target directory is usually a directory related to a specific development board, and can be determined based on factors such as the model and architecture of the development board. The target directory can be determined by a pre-established mapping relationship between the development board name and the target directory.

[0087] Step C3, calling the auxiliary construction script to automatically copy the found patch file to the target directory, and obtaining the file location of the target board configuration file.

[0088] Specifically, the auxiliary build script is called to automatically copy the found patch file to the target directory. The auxiliary build script can use file operation functions or commands to implement the file copy operation. After the copy is completed, the file location of the target board configuration file is obtained. This file location can be determined by pre-set rules or configuration information, such as determining the location of the target board configuration file based on the development board name and a specific directory structure.

[0089] Step C4, reading the file content of the target board configuration file based on the file location.

[0090] Specifically, based on the obtained file location, a file reading function or command is used to read the file content of the target board configuration file. The read file content can be stored in a data structure, such as a string, a list, etc., for subsequent processing and analysis.

[0091] Step C5, searching the file content for the original patch file path.

[0092] Specifically, the original patch file path is searched in the read file content. A string matching algorithm or regular expression can be used to search for a specific string pattern, that is, the original patch file path. This path is usually a patch file path that already exists in the previous configuration.

[0093] Step C6, calling the auxiliary construction script to add the newly added patch file path to the original patch file path, and then re-writing the modified configuration file content into the configuration file to complete the update of the configuration file.

[0094] Specifically, the auxiliary build script is called to add the extracted new patch file path to the original patch file path. The path addition operation can be implemented by using string concatenation or file editing functions. Then, the modified configuration file content is rewritten into the configuration file to complete the configuration file update. In this way, the new patch file path is successfully added to the configuration file of the target board, realizing the automatic addition of the Linux kernel patch file.

[0095] As an example, Figure 3 As shown in the figure, the process of adding a kernel patch file includes: first, the user enters the patch file name, path, and development board name. Then, check whether the patch path exists. If it does not exist, automatically create the patch path. Then, copy the patch file to the specified path, and automatically modify the patch path in the configuration file according to the development board name, thereby completing the patch addition or modification.

[0096] In the embodiment of the present application, calling the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and performing resource configuration according to the target resource configuration policy and resource description information, includes the following steps D1-D3:

[0097] Step D1: if the target resource type is to add a third-party application software tool type, then extract the software package name and the configuration file path from the resource description information.

[0098] Specifically, if the target resource type is to add a third-party application software tool type, an extraction operation is performed from the resource description information. First, the software package name is extracted. This name is key information and will be used to create configuration files related to the software package in the Buildroot directory later. At the same time, the configuration file path is also extracted. This path may be specified by the user or determined according to some rules. It will be used to add the relevant path information of the software package to the configuration file in the subsequent steps.

[0099] Step D2, calling the auxiliary build script to create a configuration file in the Buildroot directory according to the software package name.

[0100] Specifically, the auxiliary build script is called to create a configuration file in the Buildroot directory according to the software package name. The auxiliary build script can use file operation functions or specific configuration file creation tools to complete this operation. For example, a file name in a specific format can be generated according to the software package name, and a new file can be created in the Buildroot directory as a configuration file. This configuration file may be in one or more formats such as .mk, .hash, and Config.in, depending on the design and requirements of the system.

[0101] Step D3, adding the package configuration file path to the configuration file, and outputting a prompt message to the user to prompt the user to edit the configuration file created by the script.

[0102] Specifically, add the package configuration file path to the created configuration file. You can use a file editing function or a specific configuration file editing tool to achieve this operation. Add the package configuration file path to the configuration file so that Buildroot can find and use this third-party application software tool during the build process. At the same time, output a prompt message to the user to prompt the user to edit the configuration file created by the script. This prompt message can be presented to the user through a graphical interface pop-up window, command line output, or other methods. After receiving the prompt, the user can further edit and adjust the configuration file according to their needs to ensure that the third-party application software tool can be correctly integrated into the image building process.

[0103] As an example, Figure 4 As shown in the figure, the process of adding a third-party application software tool includes: first, the user enters the name of the application software tool to be added. Then, check whether the software tool already exists. If not, automatically create the .mk, .hash, and Config.in files required to add the software tool, and automatically add the software tool path to the corresponding configuration file. If the software tool already exists, prompt the user that the software tool already exists and does not need to be added repeatedly. Through this process, the software tool is added.

[0104] In the embodiment of the present application, calling the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and performing resource configuration according to the target resource configuration policy and resource description information, includes the following steps E1-E3:

[0105] Step E1: if the target resource type is a target board type, extract the target board name from the resource description information.

[0106] Specifically, if the target resource type is determined to be a target board type, the target board name is extracted from the resource description information. The target board name is key information, which will be used to determine the default configuration file associated with the target board in subsequent steps. The target board name can be specified by the user when inputting resources, or obtained by other means, such as reading from a specific configuration file.

[0107] Step E2: searching for the corresponding default configuration file in the preset storage location according to the target board name.

[0108] Specifically, according to the extracted target board name, the corresponding default configuration file is searched in the preset storage location. The preset storage location can be a specific directory or database, in which the default configuration files of various target boards are stored. The corresponding file can be found quickly and accurately by establishing a mapping relationship between the target board name and the default configuration file. For example, a hash table or a dictionary data structure can be used to store this mapping relationship so that it can be retrieved efficiently when searching.

[0109] Step E3, calling the auxiliary construction script to read the file content of the default configuration file, obtain the configuration parameters, and automatically perform the configuration operation of the target board according to the configuration parameters.

[0110] Specifically, the auxiliary build script is called to read the file content of the default configuration file. The auxiliary build script can use a file reading function or command to read the file content and store it in a data structure, such as a string, a list, or a dictionary. Configuration parameters are extracted from the file content. These parameters may include information such as the development board architecture, the cross-compilation tool chain, the Linux kernel version, and the file system type. Then, the target board configuration operation is automatically performed based on these configuration parameters. The auxiliary build script can call corresponding tools and commands to complete the configuration, such as modifying the Buildroot configuration file, executing the build command, etc. In this way, a one-step automatic build based on the target board name is achieved, without the user having to perform the defconfig configuration of the target board before performing the make build, which improves the efficiency and convenience of the build.

[0111] In the embodiment of the present application, after performing resource configuration according to the target resource configuration strategy and the resource description information, the method further includes the following steps S21-S25:

[0112] Step S21, obtaining resource configuration results, wherein the resource configuration results are obtained by the auxiliary construction script performing resource configuration according to the target resource configuration strategy and resource description information.

[0113] In an embodiment of the present application, after the auxiliary construction script performs resource configuration according to the target resource configuration strategy and resource description information, it is necessary to obtain the result of the resource configuration. This result can be obtained in a variety of ways. For example, the auxiliary construction script returns a status code or result object after completing the resource configuration, and determines whether the resource configuration is successful by reading this return value. Alternatively, the result of the resource configuration is determined by checking the status change of a specific file, directory, or database. If the resource configuration is successful, the subsequent operations are continued; if the resource configuration result shows an abnormality, further processing is required.

[0114] Step S22: If the resource configuration result shows an abnormality, a log file in the resource configuration process is obtained.

[0115] In an embodiment of the present application, if the resource configuration result shows an abnormality, a log file in the resource configuration process is obtained. The log file records detailed information in the resource configuration process, including the execution status of each operation, error information, etc. The log file can be obtained through a pre-set log file storage location, or through a specific log management tool to retrieve and obtain relevant log files. The purpose of obtaining the log file is to further analyze the cause of the abnormal resource configuration so as to take corresponding treatment measures.

[0116] Step S23, parsing the log file to obtain the target reason and target file of the abnormal display of the resource configuration result.

[0117] In an embodiment of the present application, after obtaining the log file, the log file is parsed. A log parsing tool can be used or a specific script can be written to analyze the log file. By parsing the log file, the target cause of the resource configuration result display exception and the target file related to the exception are extracted. The target cause can include various situations such as file path error, insufficient authority, and resource type mismatch. The target file is a specific file related to the exception, such as a configuration file, a patch file, a software package file, etc. By determining the target cause and the target file, more targeted treatment measures can be taken.

[0118] Step S24, obtaining a processing strategy corresponding to the target reason from a preset strategy library, and processing the target file according to the processing strategy to obtain a processed target file.

[0119] In an embodiment of the present application, a policy library is pre-established, in which processing policies corresponding to various expected resource configuration abnormality reasons are stored. According to the target reason obtained by parsing the log file, the corresponding processing policy is obtained from the preset policy library. The processing policy may include various operations such as modifying the file path, adjusting the permission setting, and reconfiguring the resource type. Then, the target file is processed according to the processing policy. The target file can be modified, adjusted or reconfigured using a file operation function, a command line tool or a specific processing script. The processed target file will be used to re-execute the resource configuration operation.

[0120] Specifically, after determining the target reason for the abnormal display of the resource configuration result, search in the preset policy library according to the target reason. If the policy library is a database, you can use SQL query statements to search according to the keywords of the target reason. If it is a configuration file, you can use the file reading and parsing functions in the programming language to traverse the entries in the configuration file and find the processing policy description that matches the target reason.

[0121] Once the processing strategy is obtained, analyze the specific content of the strategy to determine what operations need to be performed on the target file. If the processing strategy is to modify file permissions, you can use the file operation functions in the programming language to change the permission settings of the target file. For example, in Python, you can use the os.chmod() function. If the strategy is to repair the file content, you can read the content of the target file and modify it according to the specific problem. For example, if there is specific malformed data in the file, you can use string processing methods to replace or correct it. If the strategy involves restoring files from backup, first determine the location of the backup file, and then use the file copy operation to copy the backup file to the location of the target file.

[0122] After processing the target file, you need to verify whether the processing was successful. You can re-execute the part of the resource configuration operation that caused the exception to check whether the same exception still occurs. Or check specific properties of the target file, such as file size, modification time, etc., to ensure that the processed file meets expectations. If the processing is successful, the processed target file is returned as a result so that the file can be used for resource configuration operations later.

[0123] Step S25, re-execute the resource configuration operation using the processed target file.

[0124] In an embodiment of the present application, after obtaining the processed target file, the resource configuration operation is re-executed using the file. The auxiliary construction script can be called, and the processed target file is used as an input parameter to perform resource configuration again according to the target resource configuration strategy and resource description information. By re-executing the resource configuration operation, the abnormal situation that occurred before is resolved to ensure that the resource configuration can be successfully completed. If an abnormality still occurs after re-executing the resource configuration operation, steps S21-S25 can be repeated until the resource configuration is successful or other more advanced troubleshooting measures are taken.

[0125] By obtaining the resource configuration results, the configuration status can be known in a timely manner. Once it shows an abnormality, the log file of the resource configuration process can be obtained immediately. With the help of log file analysis, the target cause and target file of the abnormal resource configuration result can be accurately located, and then the corresponding processing strategy is obtained from the preset strategy library to process the target file. After the processed target file is obtained, the resource configuration operation is re-executed. In this way, a complete and efficient process for dealing with abnormalities is formed, which helps to quickly troubleshoot and solve problems in resource configuration and improve the success rate of resource configuration.

[0126] In the present embodiment, a resource configuration device of a kernel system is also provided, and the device is used to implement the above-mentioned embodiment and preferred implementation mode, and the description that has been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware is also possible and conceived.

[0127] This embodiment provides a resource configuration device for a kernel system, such as Figure 5 As shown, including:

[0128] The acquisition module 51 is used to acquire the Buildroot extension resources configured by the user for the kernel system;

[0129] A reading module 52 is used to read the target resource type and resource description information of the Buildroot extension resource;

[0130] A startup module 53 is used to start the auxiliary build script deployed in the Buildroot directory, wherein the auxiliary build script is configured with resource configuration strategies corresponding to different resource types;

[0131] The calling module 54 is used to call the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and perform resource configuration according to the target resource configuration policy and resource description information.

[0132] In an optional implementation of the present application, a reading module 52 is used to traverse the directory where the Buildroot extended resources are located to obtain resource identification information corresponding to the Buildroot extended resources; query whether there is a resource type corresponding to the resource identification information; if there is a resource type corresponding to the resource identification information, then use the resource type corresponding to the resource identification information as the target resource type; based on the association relationship between the resource type and the preset description information, read the resource description information associated with the target resource type from the directory where the Buildroot extended resources are located.

[0133] In an optional embodiment of the present application, the device also includes: a display module, which is used to display a resource type list based on a display interface if there is no resource type corresponding to the resource identification information, wherein the resource type list includes multiple resource types; detect a selection operation acting on the resource type list; and respond to the selection operation, using the resource type selected in the resource type list as the target resource type.

[0134] In an optional implementation of the present application, a calling module 54 is used to extract the development board name, patch file name and new patch file path from the resource description information if the target resource type is a new patch file type; search for the corresponding patch file in a preset storage location according to the patch file name, and determine the target directory to which the patch file is copied according to the development board name; call the auxiliary construction script to automatically copy the found patch file to the target directory, and obtain the file location of the target board configuration file; read the file content of the target board configuration file based on the file location; search for the original patch file path in the file content; call the auxiliary construction script to add the new patch file path to the original patch file path and then rewrite the modified configuration file content into the configuration file to complete the configuration file update.

[0135] In an optional embodiment of the present application, a calling module 54 is used to extract the software package name and the configuration file path from the resource description information if the target resource type is to add a third-party application software tool type; call the auxiliary build script to create a configuration file according to the software package name in the Buildroot directory; add the package configuration file path to the configuration file, and output a prompt message to the user to prompt the user to edit the configuration file created by the script.

[0136] In an optional embodiment of the present application, a calling module 54 is used to extract the target board name from the resource description information if the target resource type is a build target board type; search for the corresponding default configuration file in a preset storage location based on the target board name; call the auxiliary construction script to read the file content of the default configuration file, obtain the configuration parameters, and automatically perform the configuration operation of the target board based on the configuration parameters.

[0137] In an optional embodiment of the present application, the device also includes: a processing module, used to obtain a resource configuration result, wherein the resource configuration result is obtained by auxiliary construction scripts to configure resources according to the target resource configuration strategy and resource description information; if the resource configuration result shows an abnormality, then obtain the log file of the resource configuration process; parse the log file to obtain the target reason and target file for the abnormal resource configuration result; obtain the processing strategy corresponding to the target reason from the preset strategy library, process the target file according to the processing strategy, and obtain the processed target file; and re-execute the resource configuration operation using the processed target file.

[0138] See also Figure 6 , Figure 6 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 6 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

[0139] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0140] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0141] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the use of a computer device based on the presentation of a small program landing page, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0142] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0143] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0144] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0145] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A resource configuration method for a kernel system, characterized in that: The method comprises: Get the user's Buildroot extension resources for kernel system configuration; Read the target resource type and resource description information of the Buildroot extension resource; Start the auxiliary build script deployed in the Buildroot directory, wherein the auxiliary build script is configured with resource configuration strategies corresponding to different resource types; The auxiliary construction script is called to determine the target resource configuration policy corresponding to the target resource type, and resource configuration is performed according to the target resource configuration policy and the resource description information.

2. The method according to claim 1, characterized in that The reading of the target resource type and resource description information of the Buildroot extended resource includes: Traverse the directory where the Buildroot extension resource is located to obtain resource identification information corresponding to the Buildroot extension resource; Query whether there is a resource type corresponding to the resource identification information; If the resource type corresponding to the resource identification information exists, taking the resource type corresponding to the resource identification information as the target resource type; Based on the association relationship between the resource type and the preset description information, the resource description information associated with the target resource type is read from the directory where the Buildroot extension resource is located.

3. The method according to claim 2, characterized in that The method further comprises: If the resource type corresponding to the resource identification information does not exist, displaying a resource type list based on the display interface, wherein the resource type list includes multiple resource types; detecting a selection operation acting on the list of resource types; In response to the selection operation, the resource type selected in the resource type list is used as the target resource type.

4. The method according to claim 1, characterized in that: The calling of the auxiliary construction script to determine the target resource configuration strategy corresponding to the target resource type, and performing resource configuration according to the target resource configuration strategy and the resource description information, includes: If the target resource type is a new patch file type, the development board name, patch file name, and new patch file path are extracted from the resource description information; Search the corresponding patch file in the preset storage location according to the patch file name, and determine the target directory where the patch file is copied according to the development board name; Call the auxiliary build script to automatically copy the found patch file to the target directory and obtain the file location of the target board configuration file; Read the file content of the target board configuration file based on the file location; Searching the original patch file path in the file content; The auxiliary construction script is called to add the newly added patch file path to the original patch file path, and then the modified configuration file content is rewritten into the configuration file to complete the update of the configuration file.

5. The method according to claim 1, characterized in that The calling of the auxiliary construction script to determine the target resource configuration strategy corresponding to the target resource type, and performing resource configuration according to the target resource configuration strategy and the resource description information, includes: If the target resource type is to add a third-party application software tool type, then extract the software package name and the configuration file path from the resource description information; Call the auxiliary build script to create a configuration file in the Buildroot directory according to the software package name; The package configuration file path is added to the configuration file, and a prompt message is output to the user to prompt the user to edit the configuration file created by the script.

6. The method according to claim 1, characterized in that The calling of the auxiliary construction script to determine the target resource configuration strategy corresponding to the target resource type, and performing resource configuration according to the target resource configuration strategy and the resource description information, includes: If the target resource type is a build target board type, the target board name is extracted from the resource description information; According to the target board name, search for the corresponding default configuration file in the preset storage location; The auxiliary construction script is called to read the file content of the default configuration file, obtain configuration parameters, and automatically perform configuration operations of the target board according to the configuration parameters.

7. The method according to claim 1, characterized in that After performing resource configuration according to the target resource configuration strategy and the resource description information, the method further includes: Obtaining a resource configuration result, wherein the resource configuration result is obtained by the auxiliary construction script performing resource configuration according to the target resource configuration strategy and the resource description information; If the resource configuration result shows an abnormality, obtaining a log file during the resource configuration process; Parse the log file to obtain the target reason and target file of the abnormal display of the resource configuration result; Obtaining a processing strategy corresponding to the target cause from a preset strategy library, and processing the target file according to the processing strategy to obtain a processed target file; Re-execute the resource configuration operation using the processed target file.

8. A resource configuration device for a kernel system, characterized in that: The device comprises: The acquisition module is used to obtain the user's Buildroot extension resources for kernel system configuration; A reading module, used to read the target resource type and resource description information of the Buildroot extension resource; A startup module is used to start the auxiliary build script deployed in the Buildroot directory, wherein the auxiliary build script is configured with resource configuration strategies corresponding to different resource types; The calling module is used to call the auxiliary construction script to determine the target resource configuration policy corresponding to the target resource type, and perform resource configuration according to the target resource configuration policy and the resource description information.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images