A firmware management method, device, equipment, storage medium and program product

Abstract

The application discloses a firmware management method and device, equipment, a storage medium and a program product, relates to the technical field of computers, and according to a preset function division rule, splits target firmware into a plurality of functionally independent sub-firmwares, and encapsulates the target firmware as a plug-in and stores the target firmware in a plug-in pool. In the firmware running process, the target plug-in can be loaded, updated, unloaded, replaced or configured based on an event instruction, avoiding overall replacement of a complete firmware image. The application can operate on the target plug-in that needs to be adjusted, realizes modular management of firmware functions in a plug-in manner, solves the problems of static solidification of firmware functions and limited expansion in the related art, and achieves the technical effects of shortening the update time, reducing the system downtime risk, reducing the firmware update cost, enabling a user to flexibly select and load different function modules according to a hardware environment or a business requirement, and realizing expansion and customization of firmware functions.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and particularly relates to a firmware management method and device, equipment, a storage medium and a program product. BACKGROUND

[0002] With the rapid development of artificial intelligence technology, the iteration speed of data center and server computing power infrastructure is accelerating, and the updating and maintenance mode of server firmware as a bottom support component directly affects the stability, scalability and operation and maintenance cost of the overall computing power facility. In the related art, the server firmware (such as BIOS (Basic Input Output System), BMC (Baseboard Management Controller), UEFI (Unified Extensible Firmware Interface) and the like) is usually deployed and maintained in the form of an integral image file. This mode can meet the basic requirements in the early server application scenarios, but gradually exposes many shortcomings in the current large-scale computing power scenarios.

[0003] Firstly, the firmware updating cost is high. The updating method in the related art often needs to replace the complete firmware image and write it into the non-volatile memory. The updating process not only takes a long time, but also easily causes system downtime, brings business interruption risk, and is not conducive to the continuous and stable operation of the data center. Secondly, the firmware function extension is limited. The existing firmware functions are usually fixed in the image in a static way, and cannot be flexibly loaded and unloaded according to different hardware environments or business requirements. Server manufacturers often need to maintain multiple firmware versions for different models and configurations, increasing the development and maintenance cost, and users also have difficulty in flexibly customizing firmware functions during implementation and use, which limits the adaptability of firmware in complex and variable computing power scenarios.

[0004] Therefore, it is an urgent problem for those skilled in the art to provide a firmware management method to reduce the firmware updating cost and realize flexible extension and customization of firmware functions. SUMMARY

[0005] The present application provides a firmware management method, device, equipment, storage medium and program product to at least solve the problem of static fixation and limited extension of firmware functions in the related art.

[0006] The application provides a firmware management method, comprising: dividing target firmware into a plurality of functionally independent sub-firmwares according to a preset function division rule; packaging the plurality of sub-firmwares into plug-ins respectively, and storing the plug-ins in a plug-in pool; in response to an event instruction, determining a target plug-in and a target operation corresponding to the event instruction; and performing the target operation on the target plug-in in the plug-in pool, the target operation comprising at least one of loading, updating, uninstalling, replacing and configuring.

[0007] The application also provides a firmware management device, comprising: a division module configured to divide target firmware into a plurality of functionally independent sub-firmwares according to a preset function division rule; a packaging module configured to package the plurality of sub-firmwares into plug-ins respectively, and store the plug-ins in a plug-in pool; an instruction response module configured to, in response to an event instruction, determine a target plug-in and a target operation corresponding to the event instruction; and an operation execution module configured to perform the target operation on the target plug-in in the plug-in pool, the target operation comprising at least one of loading, updating, uninstalling, replacing and configuring.

[0008] The application also provides an electronic device, comprising: a memory configured to store a computer program; and a processor configured to implement the steps of any of the above firmware management methods when executing the computer program.

[0009] The application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of any of the above firmware management methods.

[0010] The application also provides a computer program product, comprising a computer program, and the computer program is executed by a processor to implement the steps of any of the above firmware management methods.

[0011] According to the application, the target firmware is divided into a plurality of functionally independent sub-firmwares according to a preset function division rule, and the sub-firmwares are packaged into plug-ins and stored in a plug-in pool, so that the target plug-in can be loaded, updated, uninstalled, replaced or configured based on an event instruction during firmware running, and the whole firmware image is avoided from being replaced. The application can operate on the target plug-in that needs to be adjusted, and the modular management of firmware functions is realized through the plug-in mode, thereby solving the problems of static curing of firmware functions and limited expansion in the related art, and achieving the technical effects of shortening the update time, reducing the system downtime risk, reducing the firmware update cost, enabling users to flexibly select and load different function modules according to the hardware environment or business requirements, and realizing the expansion and customization of firmware functions. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. Obviously, the drawings described below only illustrate some of the embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0013] Figure 1 A schematic diagram of an OpenBMC hierarchical decoupling modular software design provided for the embodiments of the present application.

[0014] Figure 2 A schematic diagram of an OpenBMC framework provided for the embodiments of the present application.

[0015] Figure 3 A flowchart of a firmware management method provided for the embodiments of the present application.

[0016] Figure 4 A schematic diagram of an electronic device provided for the embodiments of the present application.

[0017] Figure 5 A schematic diagram of a computer readable storage medium provided for the embodiments of the present application. DETAILED DESCRIPTION

[0018] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort under the premise of no creative effort, belong to the protection scope of the present application.

[0019] It should be noted that, in the description of the present application, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that the processes, methods, articles or devices comprising a series of elements not only include those elements, but also include other elements not explicitly listed, or include elements inherent to such processes, methods, articles or devices. The terms "first", "second" and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0020] In order to make the skilled in the art better understand the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0021] In combination with the specific application environment architecture or specific hardware architecture on which the execution of the firmware management method depends, the specific application environment architecture or specific hardware architecture is described herein. The firmware management method of the present application is applicable to the operating environment of a data center server or a high-performance computing cluster, which generally includes a hardware architecture composed of processors, memories, non-volatile storage devices, network interface cards, and various peripherals, and can be centrally managed by a management controller such as a BMC. Under this architecture, firmware serves as the underlying support for processor startup, hardware initialization, and system operation management, and its update and maintenance is directly related to the stability and scalability of the server. The present application introduces a plug-in firmware management mechanism into the above hardware architecture, enabling the firmware to be run and maintained in a modular manner, thereby enabling dynamic management of target plug-ins without interrupting the overall operation of the server, and meeting the demand for efficient, low-cost, and flexible expansion of computing infrastructure in data centers.

[0022] As Figure 1 , the software architecture of OpenBMC is divided into multiple functional layers from top to bottom, which together constitute its modular design. At the user interface level, multiple interaction methods are provided, including web graphical user interface, Redfish management interface, Intelligent Platform Management Interface, Secure Shell protocol, etc. The application layer carries core management functions such as sensor data recording, H5 virtual console, fault diagnosis, log management, system event log, media mounting, firmware management, and energy-saving cooling. These modules communicate and cooperate through an inter-process bus. The bottom layer relies on the Linux kernel and the universal bootloader, which is composed of the kernel system and the universal bootloader, and finally controls and accesses the management devices at the physical device level. Although each function is handled by an independent process, reflecting the concept of hierarchical decoupling, the firmware maintenance does not adopt a flexible modular update strategy, but still relies on the overall firmware management method, and the upgrade process requires system downtime, which cannot achieve hot updating.

[0023] Embodiments of the present application provide a firmware management method, which is described in detail in combination with the execution flow of the firmware management method. In the present application, firmware refers to a system program running at the bottom layer of a server or a computing device, used for hardware initialization, management and control, including but not limited to BIOS, BMC, UEFI, etc. The firmware is divided into a plurality of functionally independent sub-firmware, each corresponding to a specific function module of the firmware. In order to facilitate flexible management, the sub-firmware is further encapsulated into plugins that can be independently loaded or unloaded, and stored in a plugin pool. A plugin is the smallest function unit of firmware that can be independently loaded and unloaded. An event instruction refers to an external instruction or an internal trigger signal that needs to perform an operation on a plugin during firmware running, the operation including at least one of loading, updating, unloading, replacing and configuring. In order to ensure the compatibility and dependency management between plugins, a dependency resolution engine is introduced during firmware running, which functions to parse a software bill of materials (SBOM, Software Bill of Materials) file, which is used to maintain the association between a plugin and its dependencies. In addition, a plugin version includes a major version number and a minor version number, wherein the major version number is used to identify functional compatibility, and the minor version number is used to identify the degree of functional update. When there is a missing dependency, version incompatibility or version conflict between plugins, a preset strategy (such as replacement, fallback, suspension, etc.) can be used for processing, thereby ensuring the flexibility, stability and scalability of firmware functions.

[0024] As Figure 2 In embodiments of the present application, the OpenBMC-based framework divides the firmware internally into a hardware abstraction layer (HAL, Hardware Abstraction Layer), a plugin service layer (OSL, Open Service Layer) and a protocol interface layer (IPL, Interface Protocol Layer). The hardware abstraction layer is mainly used to shield the hardware differences of the underlying server, and to adapt and access various hardware through a unified interface. The plugin service layer realizes the registration and cross-process communication of plugins through the mechanism of the inter-process communication bus of OpenBMC. For example, a hard disk management plugin can access hard disk information through the path / org / openbmc / plugins / StorageMonitor at the user layer, realizing the management function of the hard disk. The design purpose of the service layer is to incorporate plugin functions into firmware system management, registration indicating enabling the function, and deregistration indicating removing the function, thereby realizing a modularized, scalable and easy-to-maintain firmware management system. The protocol interface layer contains the implementation of mainstream server management protocols (such as Redfish (Redfish protocol), PLDM (Platform Level Data Model)), ensuring seamless integration of firmware and data center operation tools, including various management operations such as firmware update.

[0025] Specifically, as Figure 3 The method comprises: S11: dividing the target firmware into a plurality of functionally independent sub-firmwares according to a preset function division rule.

[0026] Specifically, the target firmware is functionally modeled and boundary-divided. According to the preset function division rule, the functions of the firmware are mapped into a plurality of independent function domains, each of which corresponds to a functionally independent sub-firmware. The function division rule takes single responsibility, high cohesion and low coupling as the core, and partitions the code path, resource occupation and state data in combination with different functions of the firmware, such as startup, hardware initialization, device management, monitoring and alarm, network and storage control, log and configuration management, etc. At the same time, taking resource domain isolation as the premise, cross-domain access is constrained to avoid sharing variable states, and the function boundary of each sub-firmware is ensured to be clear, the state is self-consistent, and the fault influence range is controllable. It can be seen that the target firmware in the embodiment is split into a plurality of sub-firmwares with appropriate granularity, and each sub-firmware can independently complete its function target, thereby meeting the requirement of independent replacement in structure.

[0027] In a specific implementation, the function division rule also embodies a set of executable judgment criteria: including taking the function target as the division starting point (the same function closed loop belongs to the same sub-firmware), taking the life cycle as the boundary (the initialization, running and recycling processes are closed in the sub-firmware), taking the resource list as the constraint (the acquisition and release of the exclusive hardware and configuration resources of the sub-firmware must be completed within the sub-firmware), and taking the minimum interaction surface as the target (only necessary calls and data transmission are reserved between the sub-firmwares). After the above judgment is completed, the sub-firmware list and the corresponding function range description, resource access list and running precondition are formed, which are used to verify whether the division meets the requirements of function independence, clear boundary and controllable coupling. The target firmware is transformed from a whole to a plurality of functionally independent sub-firmwares in logical structure, which provides a basis for the determination and execution of the target plug-in and the target operation in the subsequent steps.

[0028] In one specific embodiment, the functional modules (e.g., hardware monitoring, data encryption, etc.) of the BMC firmware are split into independent plug-in units, each of which is encapsulated through a standardized interface (API (Application Programming Interface) / ABI (Application Binary Interface)), the interface specification uniformly defines the entry functions of the plug-in, such as init() and unload(), and adopts a uniform data exchange format (such as JSON). In addition, each plug-in complies with the protocol compatibility requirements and supports server general protocols such as Redfish to access its functional data area, thereby realizing a modular, extensible, and remotely manageable firmware function system.

[0029] S12: encapsulate the plurality of sub-firmwares into plug-ins respectively, and store the plug-ins in a plug-in pool.

[0030] Specifically, the sub-firmwares that have completed the functional division are converted into plug-in forms with independent loading and unloading capabilities. For this purpose, each sub-firmware needs to be standardized and encapsulated, so that its internal functional logic remains complete, while its basic information (such as plug-in identification, version number, dependency list, running entry, resource interface, etc.) is described through additional metadata. The encapsulation is to abstract the interaction boundary between the sub-firmware and the external environment, to ensure that the plug-in can be loaded through a fixed entry when called, and can perform resource recycling and state cleaning when unloaded, to ensure that the complete life cycle of the plug-in is controllable during runtime. It can be seen that the originally tightly coupled firmware code is modularized into a plurality of plug-in units in the embodiment, each of which can be independently executed and scheduled and managed under a unified framework.

[0031] It should be understood that the plug-in in the embodiment has independence and can be individually loaded or unloaded during system operation as needed, to realize independent calling and management of the plug-in without affecting other parts of the firmware.

[0032] After encapsulation, the plurality of plug-ins are stored in a plug-in pool for subsequent flexible retrieval according to running requirements. The plug-in pool is essentially a unified storage and indexing structure, which not only ensures the persistent storage of plug-in data in the physical medium, but also maintains the retrieval and calling mechanism at the logical level. It usually has an index table inside for quickly locating the target plug-in, and has the ability of version management and conflict detection to support the replacement and update of the plug-in. By taking the plug-in pool as a unified storage center, the management complexity caused by dispersed storage can be avoided, and the loading, updating, unloading, replacing, and configuring of the plug-in can be performed in an orderly environment, thereby laying a technical foundation for dynamic management and flexible expansion of the firmware runtime.

[0033] It needs to be understood that the plug-in pool is built in the non-volatile storage area of the firmware, and all plug-in files are saved by mounting a file directory (for example, / opt / firmware_plugins / ) independently. After the firmware operating system is started, the plug-ins can be dynamically loaded or unloaded on demand according to actual needs, flexible function extension and management are realized, and the persistence and accessibility of the plug-ins in the firmware storage are ensured.

[0034] S13: In response to the event instruction, determining a target plug-in and a target operation corresponding to the event instruction.

[0035] Specifically, the dynamic management operation of the firmware is triggered in an event-driven manner. The event instruction is usually generated by an external management system, user operation or state change detected during firmware running, for example, a function enabling request issued by the user, a security patch update requirement detected by the system or an error recovery operation found during running. In order to ensure that the firmware has adaptive ability in different application scenarios, the event instruction needs to be parsed to extract the operation target and operation intention. The determination of the target plug-in depends on the identification information or function requirement carried by the event instruction, and the determination of the target operation corresponds to a specific processing mode, for example, loading, updating or unloading. Through this event parsing mechanism, accurate positioning of the plug-in and clear assignment of the corresponding operation can be achieved under the premise of maintaining the overall running continuity of the system.

[0036] After the parsing of the event instruction is completed, the management request is mapped to the specific plug-in object in the plug-in pool according to the corresponding relationship between the target plug-in and the target operation, and the input condition is provided for the subsequent execution process. The main purpose is to decouple the external demand and the management logic of the firmware plug-in. The external system only needs to initiate a request through a standardized event instruction, and the steps of the embodiment are responsible for completing the mapping and scheduling of the plug-in level, which can ensure that different types of event instructions can be processed in a unified way, and also provides high expansibility and high flexibility for the firmware, so that it can dynamically adjust the function according to the real-time demand during running.

[0037] S14: Performing a target operation on the target plug-in in the plug-in pool, the target operation including at least one of loading, updating, unloading, replacing and configuring.

[0038] Specifically, after the event instruction is parsed into the target plug-in and the target operation, the corresponding operation needs to be performed on the target plug-in in the plug-in pool to realize the dynamic management of the firmware function. The target operation includes at least one of loading, updating, uninstalling, replacing, and configuring, each of which corresponds to a specific plug-in life cycle management process. For example, when the target operation is loading, it means that the plug-in needs to be called from the plug-in pool into the running environment for the firmware to call its function; when the target operation is uninstalling, it means that the plug-in is removed from the running environment by releasing the resources occupied by the plug-in. The firmware can flexibly adjust the enablement and disablement of the functional module according to the real-time system demand, avoid frequent replacement of the overall firmware image, and improve the running efficiency and resource utilization.

[0039] It can be seen that this step guarantees the logical independence and controllability of the operation of the target plug-in. Since the plug-ins are all stored in the plug-in pool, the corresponding operation can be directly performed on the target plug-in through a unified interface mechanism without the need for global modification of the entire firmware. This way makes the loading, updating, uninstalling, replacing, and configuring of the plug-ins independent during the running process, thereby realizing the modularization and independent loading or independent uninstalling management of the firmware function. The principle is to accurately map the target plug-in and the target operation, convert the event-driven management request into a controllable operation on a single plug-in, so that the firmware can maintain stability in a complex running environment and meet the flexible expansion and adjustment requirements of the function.

[0040] In an exemplary embodiment, further comprising: loading the plug-in by using the preset dependency parsing engine during the running of the target firmware, generating a software bill of materials file of the plug-in, and the software bill of materials file is used to maintain the association relationship between the plug-in and its dependencies; performing the target operation on the target plug-in in the plug-in pool, including: loading and parsing the software bill of materials file, determining the associated plug-in having a dependency relationship with the target plug-in; and performing the target operation on the target plug-in in the plug-in pool according to the target plug-in, the associated plug-in, and the dependency relationship.

[0041] In this embodiment, the principle of introducing the dependency parsing engine is that the firmware plug-in is not isolated during the running process, but needs to depend on external library files, licenses, or other plug-in functions to work normally. In order to avoid problems such as missing dependencies and version mismatch during plug-in loading, this embodiment parses the plug-in at runtime by using the dependency parsing engine (SBOM engine) and generates a software bill of materials file (SBOM file). The list file records the correspondence between the plug-in and its dependencies, which is equivalent to establishing a traceable and queryable dependency map. In this way, this embodiment can accurately grasp the dependency situation required by the target plug-in before performing the target operation, providing sufficient data support for subsequent loading, updating, uninstalling, replacing, and configuring.

[0042] Further, the software bill of materials file is a structured description file, and its role is not only to list the correspondence between the plug-in and the dependent item, but also to maintain the consistency and integrity of the dependent item in the running environment. The dependency resolution engine parses the dependent item of the plug-in one by one when generating the list file, ensures that each dependent item is correctly identified, thereby avoiding the situation that the plug-in cannot be normally called due to missing dependencies or incorrect dependent version. It ensures that the target plug-in can work with its dependent items in a controlled manner at firmware runtime, and also provides a basis for dynamically detecting and processing potential dependency conflicts.

[0043] When actually performing the target operation, the software bill of materials file is first loaded and parsed, and through the parsing of the list file, the associated plug-in having a dependency relationship with the target plug-in can be determined. The dependency relationship data generated in advance is mainly used to quickly and accurately locate all dependent items required by the target plug-in, avoiding the uncertainty and performance overhead caused by temporary dependency resolution during operation execution. The explicitness of the dependency relationship not only ensures that the target plug-in can successfully complete the cooperation with the associated plug-in during the loading or updating process, but also avoids operation failure caused by missing dependencies or conflicts, thereby improving the stability and usability of the firmware management method. Finally, the target operation is performed according to the target plug-in, the associated plug-in and the dependency relationship, and the life cycle operation of the plug-in is no longer an isolated behavior, but is based on the analysis and processing of the complete dependency chain.

[0044] It should be understood that the binary file of the plug-in is generated in a standardized format, and the header information thereof includes plug-in name, version number, dependency relationship and other key information. The SBOM engine parses these binary header information and generates corresponding JSON format data for describing the plug-in and its dependency relationship. The generated JSON data file is then saved in the file system, providing structured reference and traceable metadata information for plug-in loading, dependency resolution and hot update operation.

[0045] In this way, the embodiment can perform plug-in operations in a systematic manner, ensuring the consistency of the running state of the target plug-in and its dependent environment. For example, when updating the target plug-in, the associated plug-in dependent thereon can be processed synchronously, ensuring that the updated target plug-in can still normally run in the established dependent environment. The embodiment takes dependency resolution and list management as the core, realizes traceable, controllable and automatic plug-in operation, and makes the firmware function not only maintain the flexibility of modularization, but also have reliable dependency guarantee capability during the running process.

[0046] In an exemplary embodiment, performing a target operation on a target plug-in in a plug-in pool according to the target plug-in, associated plug-ins and dependency relationships comprises: determining an operation sequence of the target plug-in and the associated plug-ins according to the target plug-in, the associated plug-ins and the dependency relationships; and processing the associated plug-ins in sequence according to the operation sequence and performing the target operation on the target plug-in.

[0047] In the embodiment, the determination mechanism of the operation sequence is introduced mainly because there are dependency relationships between plug-ins, and the dependency relationships often bring constraints on the sequence. If the operation is directly performed on the target plug-in without the sequence rule, the dependency plug-in may not be ready or correctly loaded, resulting in operation failure. Therefore, before performing the target operation on the target plug-in in the plug-in pool, a reasonable operation sequence is determined based on the dependency relationships between the target plug-in and the associated plug-ins. In this way, it can be ensured that the associated plug-in depended by the target plug-in has been correctly processed when the target plug-in is processed, thereby providing a complete dependency environment for the operation of the target plug-in.

[0048] Further, after the operation sequence is determined, each associated plug-in is processed in sequence according to the sequence. The sequential processing can gradually eliminate the pre-requisites in the dependency chain, and finally make the target plug-in in a running environment that fully meets the dependency conditions. For example, when an associated plug-in is a pre-requisite dependency of the target plug-in, the related operation of the target plug-in can only proceed smoothly after the associated plug-in is correctly operated. By processing all associated plug-ins in sequence, not only can the execution risk caused by unsatisfied dependencies be avoided, but also the predictability and stability of the plug-in operation process can be improved.

[0049] Meanwhile, this sequential processing mode embodies the systematic and structured characteristics in the running process. The operation of the target plug-in and its associated plug-ins is no longer regarded as an isolated event, but is executed as a whole dependency chain, ensuring the coherence and logic of the operation. Finally, when each associated plug-in is processed in sequence, the target operation is performed on the target plug-in, so that the operation result of the target plug-in is consistent with its dependency environment, thereby realizing effective management of the plug-in life cycle and stable running of the firmware function.

[0050] In an exemplary embodiment, determining an operation sequence of the target plug-in and the associated plug-ins according to the target plug-in, the associated plug-ins and the dependency relationships comprises: constructing a directed acyclic graph according to the target plug-in, the associated plug-ins and the dependency relationships; and performing a topological sorting on the target plug-in and the associated plug-ins according to the directed acyclic graph to determine the operation sequence of the target plug-in and the associated plug-ins.

[0051] In this embodiment, the target plug-in and the associated plug-in and their dependency relationship are abstracted as a directed acyclic graph (DAG) to represent the dependency relationship between the plug-ins. Each plug-in corresponds to a node in the graph. If plug-in A depends on plug-in B, a directed edge is established from B to A in the graph, indicating that the operation of B must be completed before the operation of A. This graph structure can clearly express the dependency relationship between the plug-ins, avoid circular dependency, and provide a basis for determining a reasonable operation order subsequently.

[0052] Based on the constructed directed acyclic graph, the plug-ins are sorted by a topological sorting algorithm to determine the order of plug-in operations. Topological sorting can ensure that all dependent nodes of each node are processed before it, thereby ensuring that the associated plug-ins on which a target plug-in depends have been loaded or updated before the target operation of the target plug-in is performed. For example, if C is a dependency of B, and B is a dependency of A, the sorting result is [C, B, A], which ensures that C is executed before B, and B is executed before A, thereby maintaining the dependency integrity of the operation process.

[0053] Through this topological sorting based on the directed acyclic graph, the order of plug-in operations can be managed, operation failures or exceptions caused by unmet dependencies can be avoided, and it is ensured that all associated plug-ins on which a target plug-in depends are ready when the target plug-in performs a target operation, thereby improving the stability of plug-in operations and the reliability of firmware functions.

[0054] In an exemplary embodiment, after loading and parsing the software bill of materials file and determining the associated plug-ins that have a dependency relationship with the target plug-in, the method further includes: determining whether the associated plug-ins that have a dependency relationship with the target plug-in meet preset requirements, the preset requirements including that the associated plug-ins are not missing and that the versions of the associated plug-ins are compatible with the target plug-in; and if the preset requirements are met, performing the step of performing a target operation on the target plug-in in the plug-in pool according to the target plug-in, the associated plug-ins, and the dependency relationship.

[0055] In this embodiment, the software bill of materials file corresponding to the target plug-in is loaded and parsed to identify the associated plug-ins on which the target plug-in depends. The software bill of materials file records the dependency information of the plug-ins, including the name, version number, and other necessary attributes of the dependent plug-ins. These information can clearly describe the dependency relationship between the target plug-in and its associated plug-ins. By parsing the bill of materials file, all associated plug-ins required by the target plug-in can be quickly located, providing a complete dependency basis for subsequent operations.

[0056] After identifying the associated plugins, a check is performed on each associated plugin to determine whether it meets preset requirements. The preset requirements include two aspects. First, the associated plugin must exist, i.e., it must not be missing. Second, the version of the associated plugin must be compatible with the target plugin, to ensure that the plugin will not have functional conflicts or operational abnormalities when loaded or executed. By determining whether the associated plugin meets these requirements, potential problems can be discovered in advance before the target operation is performed, thereby avoiding operation failure due to unmet dependencies.

[0057] When all the associated plugins meet the preset requirements, the target operation is performed on the target plugin in the plugin pool according to the dependency relationship between the target plugin and the associated plugins. This step ensures that the associated plugins on which the target plugin depends are ready and compatible in version when the target plugin performs a loading, updating, uninstalling, replacing, or configuring operation, thereby ensuring the safety and reliability of the operation. At the same time, through dependency checking and version verification, the order of the plugin operation is realized.

[0058] It should be understood that the version of the dependency of the target plugin is checked, and the input includes the version of the locally installed dependency (the dependency is the associated plugin) and the dependency that has been marked as missing or version incompatible. By parsing the version number of each dependency and using a regular expression to perform downward compatible matching on the version (for example, version 2.3.0 indicates compatibility with all 2.x versions (x is a natural number)), it is determined whether the current dependency meets the compatibility requirements of the target plugin, thereby determining whether an alternative plugin needs to be selected, a version needs to be rolled back, or the target operation needs to be aborted.

[0059] In an exemplary embodiment, after determining whether the associated plugins that have a dependency relationship with the target plugin meet the preset requirements, the method further includes: if the preset requirements are not met, marking the associated plugins that do not meet the preset requirements, and determining whether there is an alternative plugin that replaces the associated plugins that do not meet the preset requirements, and if there is no alternative plugin, marking the associated plugins that do not meet the preset requirements as damaged plugins.

[0060] In this embodiment, when it is determined that the associated plugins of the target plugin do not meet the preset requirements, the associated plugins that do not meet the requirements are marked. The purpose of marking is to clearly distinguish between normal plugins and problematic plugins, so that they can be managed and operated in a targeted manner in subsequent processing. Through marking, the associated plugins that do not meet the requirements can be tracked and recorded, providing a basis for subsequent repair, replacement, or rollback operations.

[0061] If there is a suitable alternative plugin, the alternative plugin is preferentially selected for loading, thereby avoiding operation failure caused by the associated plugin not meeting the requirements. If it is judged that there is no available alternative plugin, the associated plugin that does not meet the requirements is marked as a damaged plugin. The marking of the damaged plugin is used to prompt the user or the operation and maintenance system that the plugin has a problem and needs to be further processed or hot updated and repaired.

[0062] The embodiment can identify a risk plugin in time in the case of incomplete plugin dependency relationship, thereby ensuring the safety and stability of overall system operation.

[0063] In an exemplary embodiment, after judging whether the associated plugin in the dependency relationship with the target plugin meets the preset requirements, the method further includes: if the preset requirements are not met and the associated plugin is missing, performing a missing dependency processing operation, the missing dependency processing operation including at least one of missing dependency prompting, missing associated plugin loading, alternative plugin selection, and target operation suspension of the target plugin.

[0064] In the embodiment, when it is judged that the associated plugin of the target plugin does not meet the preset requirements and is missing, a missing dependency processing operation is triggered. The purpose is to cope with the dependency interruption risk caused by the missing associated plugin, so as to ensure that the target plugin does not abnormally or fail when performing the target operation due to incomplete dependency.

[0065] Specifically, the missing dependency processing operation can include issuing a missing dependency prompt to the user or the operation and maintenance system, which explicitly indicates which associated plugins are missing, helping the user to take measures for repair or loading in time. The missing associated plugin can also be automatically supplemented and loaded, the missing plugin is obtained from a plugin pool or an external resource, the complete dependency relationship is restored, and the normal execution of the target plugin is ensured.

[0066] In addition, if there is a function-compatible alternative plugin, the alternative plugin can be selected to replace the missing plugin, thereby meeting the dependency relationship requirements. If the missing plugin cannot be supplemented or the alternative plugin cannot be found, the target operation of the target plugin can be suspended, so as to avoid abnormal behavior or system instability caused by missing dependency. Through these measures, the stability and reliability of the system can be effectively ensured in the case of missing plugin dependency.

[0067] In an exemplary embodiment, after determining whether the associated plug-in satisfying the preset requirement, if the preset requirement is not satisfied and the version of the associated plug-in is incompatible with the target plug-in, a version-incompatible processing operation is performed, and the version-incompatible processing operation includes at least one of selecting a substitute plug-in, version rollback, and suspending the target operation of the target plug-in.

[0068] In the embodiment, when it is determined that the version of the associated plug-in of the target plug-in is incompatible with the target plug-in, a version-incompatible processing operation is triggered to ensure the correctness of the plug-in dependency and the stability of the system. The version incompatibility may cause the target plug-in to function abnormally or fail to run when performing the target operation, and thus needs to be processed in advance to avoid potential risks.

[0069] Specifically, the version-incompatible processing operation can include selecting a substitute plug-in, that is, finding a compatible version of the associated plug-in from the plug-in pool as a substitute to satisfy the dependency and ensure the normal execution of the target plug-in. Another processing manner is version rollback, that is, downgrading the incompatible associated plug-in to a compatible version of the target plug-in to restore the correct dependency. If a compatible substitute plug-in cannot be found or version rollback is not possible, the target operation of the target plug-in is suspended to avoid abnormal behavior or system instability caused by version conflicts. Through the above processing measures, the safety and reliability of the plug-in operation can be maintained in the case of incompatible versions of the associated plug-in.

[0070] In an exemplary embodiment, the process of selecting a substitute plug-in includes: determining whether there is a substitute plug-in that is downward compatible with the target plug-in; if there is, the substitute plug-in is loaded as the version-incompatible associated plug-in, and the target operation of the target plug-in is performed based on the substitute plug-in and other version-compatible associated plug-ins.

[0071] In the embodiment, when it is detected that the version of the associated plug-in of the target plug-in is incompatible, the process of selecting a substitute plug-in is started to ensure that the target plug-in can perform the target operation in an environment that meets the dependency. The main step is to determine whether there is a substitute plug-in that is downward compatible with the target plug-in, and by comparing the major version number and the minor version number of the plug-in, it can be determined whether the plug-in is compatible in function and dependency, thereby ensuring that the substitute plug-in can correctly replace the incompatible associated plug-in.

[0072] Once the downward compatible substitute plug-in is found, it is loaded as the version-incompatible associated plug-in and replaces the original incompatible plug-in in the plug-in pool. After the substitute plug-in is loaded, the target operation of the target plug-in is performed based on the substitute plug-in and other associated plug-ins that have met the version compatibility, to ensure that the operation sequence and the dependency are correctly maintained.

[0073] The embodiment can flexibly handle plug-in version conflicts without destroying system stability, avoid target plug-in execution failure or function abnormality caused by version incompatibility, and thus improve firmware updating and management reliability.

[0074] In an exemplary embodiment, the plug-in includes a major version number and a minor version number; the major version number represents plug-in function compatibility, and the minor version number represents plug-in function update degree; and the judgment whether there is a substitute plug-in downward compatible with the target plug-in includes: judging whether there is a plug-in with the same major version number as the major version number of the associated plug-in incompatible in version and with the minor version number less than the minor version number of the associated plug-in incompatible in version; if there is, determining that there is a substitute plug-in downward compatible with the target plug-in, and selecting the plug-in with the same major version number as the major version number of the associated plug-in incompatible in version and with the minor version number less than the minor version number of the associated plug-in incompatible in version but with the latest minor version number as the substitute plug-in.

[0075] In the embodiment, the plug-in is identified by a major version number and a minor version number, wherein the major version number is used to represent plug-in function compatibility, ensuring that the plug-in can correctly cooperate with the target plug-in and its dependent plug-ins in function; and the minor version number is used to represent plug-in function update degree, reflecting the improvement and enhancement of the plug-in within the same function compatibility range. Through this version identification method, the plug-in can be finely managed, so as to quickly judge whether the plug-in is available when handling version conflicts.

[0076] The process of judging whether there is a substitute plug-in downward compatible with the target plug-in is realized by comparing version numbers. Specifically, the plug-in with the same major version number as the major version number of the associated plug-in incompatible in version is found in the plug-in pool, and at the same time, the minor version number is less than the minor version number of the associated plug-in incompatible in version. It is ensured that the selected substitute plug-in is consistent in function compatibility, and at the same time, the update degree does not exceed the original plug-in, so as to avoid introducing new incompatibility risks.

[0077] If the above conditions are met, it is determined that there is a substitute plug-in downward compatible with the target plug-in, and the plug-in with the latest minor version number is selected from the candidate plug-in as the final substitute plug-in. By selecting the plug-in with the latest minor version number, the latest functions and optimizations of the plug-in can be used as much as possible under the premise of ensuring compatibility, so as to improve the function integrity and running efficiency of the system.

[0078] It can be seen that the embodiment can automatically identify and load the most suitable substitute plug-in under the condition of version conflict, so as to ensure that the target operation of the target plug-in can be smoothly executed, reduce human intervention, and enhance the automation and reliability of the plug-in management and firmware updating process.

[0079] In an example embodiment, after determining whether there is a substitute plug-in downward compatible with the target plug-in, the method further comprises: if there is no substitute plug-in, aborting the target operation of the target plug-in, and determining the version-incompatible associated plug-in as a damaged plug-in, and reporting damage information to wait for a user to perform a hot update recovery operation on the damaged plug-in.

[0080] In the embodiment, when it is determined that there is no substitute plug-in downward compatible with the target plug-in, it indicates that there is no available plug-in in the current plug-in pool that can replace the version-incompatible associated plug-in while maintaining functional compatibility. In order to avoid introducing functional conflicts or causing system abnormalities when performing the target operation of the target plug-in, the target operation of the target plug-in is aborted to ensure the stability and security of the overall firmware operation.

[0081] Meanwhile, the version-incompatible associated plug-in is marked as a damaged plug-in to clearly indicate that there is a problem with the current plug-in. The marking facilitates the management and maintenance of the plug-in pool, provides a basis for subsequent repair operations, and enables operations and maintenance personnel to quickly locate the problem plug-in.

[0082] At the same time, damage information is reported to wait for a user to perform a hot update recovery operation. Through the reporting, the user can perform online updating or replacing of the damaged plug-in without affecting the operation of other plug-ins, thereby realizing continuous and reliable operation and automated management of the firmware.

[0083] In an example embodiment, after loading and parsing the software bill of materials file and determining the associated plug-in that has a dependency relationship with the target plug-in, the method further comprises: if there are a first plug-in and a second plug-in in the plug-in set composed of the target plug-in and the associated plug-in, both of which depend on a third plug-in, and the first plug-in depends on a first version of the third plug-in and the second plug-in depends on a second version of the third plug-in, the first version being different from the second version, performing a version conflict handling operation; the version conflict handling operation comprises at least one of selecting a compatible version of the third plug-in and performing version rollback on the third plug-in, and aborting the target operation of the target plug-in.

[0084] In the embodiment, when it is detected that there are a first plug-in and a second plug-in in the plug-in set composed of the target plug-in and the associated plug-in, both of which depend on the same third plug-in, but the versions of the third plug-in they depend on are different (i.e., the first version is inconsistent with the second version), it indicates that there is a version conflict. If not handled, directly loading the third plug-in may cause functional abnormalities of the first plug-in or the second plug-in, or even affect the stable operation of the entire plug-in set.

[0085] In order to ensure the normal operation of the plug-in set, a version conflict handling operation is performed. The handling operation includes selecting a compatible version of the third plug-in, which can meet the functional requirements of the first plug-in and the second plug-in on the third plug-in, and eliminating the incompatibility risk caused by the version conflict.

[0086] In addition, the processing operation of the version conflict further includes version rollback of the third plug-in, i.e., rollback of the third plug-in to a previous stable version in necessary cases, to ensure consistency of the current plug-in set in terms of functions and dependencies. If a compatible version cannot be found or the rollback solution cannot solve the conflict, the target operation of the target plug-in is aborted, thereby avoiding triggering system exceptions or plug-in function failures when there is a version conflict.

[0087] In an exemplary embodiment, the plug-in includes a major version number and a minor version number; the major version number represents function compatibility of the plug-in, and the minor version number represents a function update degree of the plug-in; the process of selecting a compatible version of the third plug-in includes: judging whether the major version number corresponding to the first version is same as the major version number corresponding to the second version; if the major version numbers are same, comparing the minor version number corresponding to the first version with the minor version number corresponding to the second version; and taking the third plug-in corresponding to the version with the smaller minor version number as the compatible version of the third plug-in.

[0088] In the embodiment, each plug-in includes a major version number and a minor version number, wherein the major version number is used to represent function compatibility of the plug-in, i.e., to determine whether the plug-in can work with other plug-ins in terms of functions, and the minor version number is used to represent a function update degree of the plug-in, i.e., to represent an update or improvement of the plug-in under the same function compatibility. By refining the version information of the plug-in, compatibility between different plug-ins can be determined, and reasonable processing can be performed in the case of version conflict.

[0089] When a compatible version of the third plug-in needs to be selected, first, it is judged whether the major version number of the first version is same as the major version number of the second version. If the major version numbers are same, it indicates that the first version and the second version are consistent in terms of function compatibility, and selection can be considered at the level of the minor version number, to ensure consistency of plug-in functions. Under the premise of the same major version numbers, the minor version numbers of the first version and the second version are further compared. The plug-in corresponding to the version with the smaller minor version number usually contains basic functions and has less updates, and the potential incompatibility risk or function conflict is reduced while maintaining function compatibility.

[0090] Finally, the third plug-in corresponding to the version with the smaller minor version number is selected as the compatible version of the third plug-in, and relevant plug-ins are loaded based on the version, to ensure that the plug-ins in the plug-in set are consistent in terms of function compatibility and dependencies, and function abnormalities or running errors caused by inconsistent versions are avoided.

[0091] In an exemplary embodiment, the process of selecting a compatible version of the third plug-in comprises: determining the loading order of the first plug-in and the second plug-in according to the dependency relationship; taking the version of the third plug-in on which the plug-in to be loaded preferentially depends as the current compatible version of the third plug-in, and loading the plug-in to be loaded preferentially based on the current compatible version; when loading a subsequent plug-in, upgrading or downgrading the current compatible version of the third plug-in so that the version of the third plug-in processed is consistent with the version of the third plug-in on which the subsequent plug-in depends, updating the version of the third plug-in processed as a new compatible version, and loading the subsequent plug-in based on the new compatible version; wherein, when the first plug-in is the plug-in to be loaded preferentially, the second plug-in is the subsequent plug-in; when the second plug-in is the plug-in to be loaded preferentially, the first plug-in is the subsequent plug-in.

[0092] In the embodiment, when it is necessary to select a compatible version of the third plug-in in the plug-in set, the loading order can also be determined according to the dependency relationship between the plug-ins. By analyzing the dependency relationship of the first plug-in and the second plug-in on the third plug-in, it can be determined which plug-in should be loaded preferentially to ensure the integrity of the dependency chain and the correctness of the operation order, thereby avoiding functional abnormalities caused by improper loading order.

[0093] After the loading order is determined, the version of the third plug-in on which the plug-in to be loaded preferentially depends is taken as the current compatible version of the third plug-in, and the plug-in to be loaded preferentially is loaded based on the version. The purpose of this step is to ensure that the plug-in to be loaded initially can normally operate on the version of the third plug-in required by the plug-in, and to provide a basic compatible environment for subsequent plug-ins.

[0094] When loading a subsequent plug-in, the current compatible version of the third plug-in is upgraded or downgraded so that the version of the third plug-in is consistent with the version of the third plug-in on which the subsequent plug-in depends. Through this dynamic adjustment, the version requirements for the third plug-in in the plug-in set can be unified under the premise of ensuring compatibility, the influence of version conflicts on functional execution can be avoided, and the version of the third plug-in processed is updated as a new compatible version to serve as a reference for loading subsequent plug-ins.

[0095] In specific operations, if the first plug-in is the plug-in to be loaded preferentially, the second plug-in is the subsequent plug-in; otherwise, if the second plug-in is the plug-in to be loaded preferentially, the first plug-in is the subsequent plug-in. This mechanism ensures that the third plug-in always remains version compatible regardless of the loading order of the plug-ins, thereby realizing stable loading and correct execution of the entire plug-in set.

[0096] It needs to be understood that the same point of the two embodiments of selecting the compatible version of the third plug-in is that the dependency of each plug-in in the plug-in set on the third plug-in is processed, and the purpose is to ensure that all plug-ins can normally operate under the uniform and compatible version of the third plug-in. Both methods consider the major version number and the minor version number of the plug-in version for judging the function compatibility and the function update degree, so as to select a compatible version of the third plug-in that meets the dependency requirement, to avoid the influence of version conflict on the target operation. The difference lies in that the first embodiment focuses on directly comparing the major version number and the minor version number of the dependent plug-in, and selects the plug-in with the smaller minor version number as the compatible version, the operation is relatively static and direct, the efficiency is high, and it is suitable for the scene where the dependency relationship is relatively clear and the number of plug-ins is small; and the second embodiment introduces the concept of plug-in loading sequence, determines the initial compatible version by preferentially loading the plug-in, and then dynamically upgrades or downgrades the third plug-in when loading the subsequent plug-in, so as to realize the dynamic adjustment and update of the version during the loading process, and ensure that all dependent plug-ins can still be compatible and run in a complex and multi-version coexistence environment, which is more suitable for complex scenes where multiple plug-ins depend on the same third plug-in but have inconsistent versions.

[0097] In an exemplary embodiment, after the plurality of sub-firmwares are encapsulated into plug-ins respectively and the plug-ins are stored in the plug-in pool, the method further comprises: defining a uniform calling interface for the plug-ins, the calling interface comprising at least a standardized initialization interface, a function execution interface and a state query interface; and performing a target operation on a target plug-in in the plug-in pool, comprising: performing the target operation on the target plug-in by calling a function interface corresponding to the uniform calling interface.

[0098] In the embodiment, each sub-firmware is encapsulated into an independent plug-in that can be independently loaded or unloaded, and is stored in the plug-in pool. After that, a uniform calling interface is defined for the plug-ins, which can ensure that each plug-in has a standardized interaction mode in the firmware system. The calling interface comprises at least an initialization interface, a function execution interface and a state query interface, which are respectively used for the startup initialization, function logic execution and running state monitoring of the plug-in, thereby realizing the decoupling of the plug-in and the firmware management method, and enabling each plug-in to be independently developed, independently tested and uniformly called.

[0099] When performing a target operation on a target plug-in in the plug-in pool, a function interface conforming to the uniform calling interface is called to realize the dynamic control of the plug-in, including loading, updating, unloading, replacing and configuring operations. This mechanism ensures the consistency and controllability of plug-in operations, and avoids the high cost and high risk caused by directly modifying the overall firmware image.

[0100] By using the OpenBMC native Linux dynamic loading technology, each plugin exists in the form of an independent process in the firmware system. Through the provided dlopen and dlsym interfaces, plugin functions can be loaded and bound at runtime, thereby realizing dynamic loading and functional expansion of the plugin without restarting the server. This runtime dynamic loading mechanism not only improves the flexibility of firmware functions, but also significantly reduces the operation and maintenance cost of updating and expanding plugins, thereby ensuring the continuous operation capability of the data center and server system.

[0101] In an exemplary embodiment, when the target operation is updating, performing the target operation on the target plugin in the plugin pool includes: in response to an update instruction for the target plugin, obtaining new version data of the target plugin; writing the new version data into a position corresponding to the target plugin in the plugin pool to replace old version data; and triggering the target firmware to reload the target plugin in the plugin pool at runtime to complete hot updating.

[0102] In this embodiment, when the target operation is updating, in response to an update instruction for the target plugin, new version data of the target plugin is obtained from a specified data source or update package, ensuring that the plugin can obtain the latest functional logic or security repair content and prepare for subsequent hot updating operations. Subsequently, the obtained new version data is written into a position corresponding to the target plugin in the plugin pool to replace the original old version data. This process does not affect the operation of other plugins in the plugin pool, and version iteration of a single plugin is realized through local updating, avoiding the system downtime risk caused by overall firmware image replacement. Finally, the target firmware is triggered to reload the target plugin in the plugin pool at runtime, so that the new version plugin takes effect and hot updating is realized. Through the runtime dynamic loading mechanism, the updating operation can be completed while the system continues to run, thereby improving the efficiency and flexibility of firmware updating and ensuring the continuous and stable operation of the server system and the data center.

[0103] In a specific embodiment, when performing hot updating of firmware plugins, the data center management node accesses the BMC node of the target server and calls the SBOM engine to build a list of firmware functional plugins. The plugin list includes detailed information of all functional plugins in the firmware, such as plugin loading state, version information, dependency relationship, and uniform calling interface specification, etc., which are used to support subsequent dependency resolution and version management operations. Subsequently, the data center hot updating tool accesses the hot updating plugin database on the management node, generates an update instruction for the target plugin according to the SBOM list and actual upgrade requirements. The update instruction is sent to the target server to trigger the updating operation of the target plugin in the plugin pool in the firmware management method, including obtaining new version data and preparing to replace the old version plugin.

[0104] When the SBOM engine receives the hot update instruction during firmware runtime, it re-scans the local plugin pool and triggers the dynamic loading operation of the target plugin. The entire loading process follows the transactional atomic update rule, including backing up the old version of the plugin, downloading the new version of the data, verifying the signature legality, replacing the plugin, and timely rolling back to the old version when the loading fails, thereby realizing safe, continuous, and controllable hot update.

[0105] Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment.

[0106] The embodiment of the present application further provides a firmware management apparatus, comprising: a division module configured to divide a target firmware into a plurality of functionally independent sub-firmwares according to a preset function division rule; an encapsulation module configured to encapsulate the plurality of sub-firmwares into plugins respectively, and store the plugins in a plugin pool; an instruction response module configured to determine a target plugin and a target operation corresponding to an event instruction in response to the event instruction; and an operation execution module configured to execute the target operation on the target plugin in the plugin pool, the target operation comprising at least one of loading, updating, uninstalling, replacing and configuring.

[0107] The features of the embodiments corresponding to the firmware management apparatus can be referred to the related descriptions of the embodiments of the firmware management method, which will not be repeated here.

[0108] As Figure 4 The embodiment of the present application further provides an electronic device, comprising a memory 101 and a processor 102, the memory 101 stores a computer program, and the processor 102 is configured to run the computer program to execute the steps in any of the above firmware management method embodiments.

[0109] As Figure 5 The embodiment of the present application further provides a computer readable storage medium 201, which stores a computer program 202, wherein the computer program 202 is configured to execute the steps in any of the above firmware management method embodiments when running.

[0110] In an exemplary embodiment, the above computer readable storage medium 201 can include but is not limited to: a U disk, a read-only memory (Read-Only Memory, ROM for short), a random access memory (Random Access Memory, RAM for short), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs 202.

[0111] The embodiment of the present application further provides a computer program product, which comprises a computer program, and the computer program realizes the steps in any of the foregoing firmware management method embodiments when executed by a processor.

[0112] The embodiment of the present application further provides another computer program product, which comprises a nonvolatile computer readable storage medium, and the nonvolatile computer readable storage medium stores a computer program, and the computer program realizes the steps in any of the foregoing firmware management method embodiments when executed by a processor.

[0113] Those skilled in the art can further understand that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in the foregoing description in general terms. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0114] The foregoing provides a firmware management method, device, equipment, storage medium and program product. The principles and implementation manners of the present application are described by applying specific examples. The foregoing description of the examples is only applicable to help understand the method and core idea of the present application. It should be noted that, for those skilled in the art, without departing from the principles of the present application, some improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A firmware management method, characterized by, The method comprises the following steps: dividing the target firmware into a plurality of functionally independent sub-firmwares according to a preset function division rule; encapsulating the plurality of sub-firmwares into plug-ins respectively, and storing the plug-ins in a plug-in pool; determining a target plug-in corresponding to an event instruction and a target operation in response to the event instruction; performing the target operation on the target plug-in in the plug-in pool, the target operation comprising at least one of loading, updating, uninstalling, replacing and configuring; The method further comprises the following steps: loading the plug-ins by using a preset dependency resolution engine during runtime of the target firmware, and generating a software bill of materials file of the plug-ins, the software bill of materials file being used to maintain an association relationship between the plug-ins and their dependencies; performing the target operation on the target plug-in in the plug-in pool comprises the following steps: loading and parsing the software bill of materials file to determine associated plug-ins having a dependency relationship with the target plug-in; performing the target operation on the target plug-in in the plug-in pool according to the target plug-in, the associated plug-ins and the dependency relationship.

2. The firmware management method according to claim 1, wherein performing the target operation on the target plug-in in the plug-in pool according to the target plug-in, the associated plug-ins and the dependency relationship comprises the following steps: determining an operation sequence of the target plug-in and the associated plug-ins according to the target plug-in, the associated plug-ins and the dependency relationship; processing the associated plug-ins in the operation sequence one by one, and performing the target operation on the target plug-in.

3. The firmware management method according to claim 2, wherein determining an operation sequence of the target plug-in and the associated plug-ins according to the target plug-in, the associated plug-ins and the dependency relationship comprises the following steps: constructing a directed acyclic graph according to the target plug-in, the associated plug-ins and the dependency relationship; topologically sorting the target plug-in and the associated plug-ins according to the directed acyclic graph to determine the operation sequence of the target plug-in and the associated plug-ins.

4. The firmware management method of claim 1, wherein, After loading and parsing the software bill of materials file to determine associated plug-ins having a dependency relationship with the target plug-in, the method further comprises the following steps: judging whether the associated plug-ins having the dependency relationship with the target plug-in meet preset requirements, the preset requirements comprising that the associated plug-ins are not missing and versions of the associated plug-ins are compatible with the target plug-in; if the preset requirements are met, performing the step of performing the target operation on the target plug-in in the plug-in pool according to the target plug-in, the associated plug-ins and the dependency relationship.

5. The firmware management method according to claim 4, wherein After judging whether the associated plug-ins having the dependency relationship with the target plug-in meet preset requirements, the method further comprises the following steps: if the preset requirements are not met, marking the associated plug-ins not meeting the preset requirements, and judging whether there is a replacement plug-in replacing the associated plug-ins not meeting the preset requirements, if there is no replacement plug-in, marking the associated plug-ins not meeting the preset requirements as damaged plug-ins.

6. The firmware management method according to claim 4, wherein After judging whether the associated plug-ins having the dependency relationship with the target plug-in meet preset requirements, the method further comprises the following steps: If the preset requirement is not met and the associated plug-in is missing, a missing dependency processing operation is performed, the missing dependency processing operation including at least one of missing dependency prompting, missing associated plug-in supplementary loading, alternative plug-in selection, and target operation of the target plug-in suspension.

7. The firmware management method of claim 4, wherein, After judging whether the associated plug-in having a dependency relationship with the target plug-in meets a preset requirement, the method further includes: If the preset requirement is not met and the version of the associated plug-in is incompatible with the target plug-in, a version-incompatible processing operation is performed, the version-incompatible processing operation including at least one of alternative plug-in selection, version rollback, and target operation of the target plug-in suspension.

8. The firmware management method according to claim 7, wherein The alternative plug-in selection process includes: Judging whether there is an alternative plug-in downward compatible with the target plug-in; If there is, the alternative plug-in is loaded as the version-incompatible associated plug-in, and the target operation of the target plug-in is performed based on the alternative plug-in and other version-compatible associated plug-ins.

9. The firmware management method of claim 8, wherein, The plug-in includes a major version number and a minor version number; the major version number represents functional compatibility of the plug-in, and the minor version number represents a functional update degree of the plug-in; Judging whether there is an alternative plug-in downward compatible with the target plug-in includes: Judging whether there is a plug-in having a same major version number as the version-incompatible associated plug-in and a minor version number smaller than that of the version-incompatible associated plug-in; If there is, it is determined that there is an alternative plug-in downward compatible with the target plug-in, and the plug-in having the same major version number as the version-incompatible associated plug-in and the minor version number smaller than that of the version-incompatible associated plug-in but the latest minor version number is taken as the alternative plug-in.

10. The firmware management method of claim 8, wherein, After judging whether there is an alternative plug-in downward compatible with the target plug-in, the method further includes: If there is no alternative plug-in, the target operation of the target plug-in is suspended, the version-incompatible associated plug-in is determined as a damaged plug-in, and damaged information is reported to wait for a user to perform a hot update recovery operation on the damaged plug-in.

11. The firmware management method according to any one of claims 1 to 10, wherein, After loading and parsing the software bill of materials file to determine the associated plug-in having a dependency relationship with the target plug-in, the method further includes: If there are a first plug-in and a second plug-in simultaneously dependent on a third plug-in in a plug-in set composed of the target plug-in and the associated plug-in, and the first plug-in is dependent on a first version of the third plug-in and the second plug-in is dependent on a second version of the third plug-in, the first version is different from the second version, a version conflict processing operation is performed. The version conflict processing operation includes at least one of selection of a compatible version of the third plug-in, version rollback of the third plug-in, and target operation of the target plug-in suspension.

12. The firmware management method of claim 11, wherein, The plug-in includes a major version number and a minor version number; the major version number represents functional compatibility of the plug-in, and the minor version number represents a functional update degree of the plug-in; The process of selection of a compatible version of the third plug-in includes: Judging whether the major version number corresponding to the first version is same as the major version number corresponding to the second version; If the major version numbers are the same, compare the minor version number corresponding to the first version with the minor version number corresponding to the second version; If the minor version number corresponding to the first version is smaller than the minor version number corresponding to the second version, the third plug-in corresponding to the minor version number is the third plug-in of the compatible version.

13. The firmware management method of claim 11, wherein, The process of selecting a third plug-in of a compatible version includes: According to the dependency relationship, determining the loading order of the first plug-in and the second plug-in; loading the plug-in as a third plug-in of a current compatible version, and loading the plug-in based on the third plug-in of the current compatible version; When loading a subsequent plug-in, performing upgrade or downgrade processing on the third plug-in of the current compatible version, so that the version of the processed third plug-in is consistent with the version of the third plug-in depended by the subsequent plug-in, updating the version of the processed third plug-in as a new compatible version, and loading the subsequent plug-in based on the new compatible version; When the first plug-in is the plug-in to be loaded preferentially, the second plug-in is the subsequent plug-in; when the second plug-in is the plug-in to be loaded preferentially, the first plug-in is the subsequent plug-in.

14. The firmware management method of claim 1, wherein, After encapsulating the plurality of sub-firmwares into plug-ins respectively and storing the plug-ins in a plug-in pool, the method further includes: defining a unified calling interface for the plug-ins, the calling interface including at least a standardized initialization interface, a function execution interface, and a state query interface; performing the target operation on a target plug-in in the plug-in pool includes: performing the target operation on the target plug-in by calling a function interface corresponding to the unified calling interface.

15. The firmware management method of claim 1, wherein, When the target operation is updating, performing the target operation on a target plug-in in the plug-in pool includes: in response to an update instruction for the target plug-in, obtaining new version data of the target plug-in; writing the new version data into a position in the plug-in pool corresponding to the target plug-in to replace old version data; triggering the target firmware runtime to reload the target plug-in in the plug-in pool to complete hot updating.

16. A firmware management apparatus, characterized by comprising: includes: a division module, configured to divide a target firmware into a plurality of functionally independent sub-firmwares according to a preset function division rule; an encapsulation module, configured to encapsulate the plurality of sub-firmwares into plug-ins respectively and store the plug-ins in a plug-in pool; an instruction response module, configured to determine a target plug-in and a target operation corresponding to an event instruction in response to the event instruction; an operation execution module, configured to perform the target operation on a target plug-in in the plug-in pool, the target operation including at least one of loading, updating, uninstalling, replacing, and configuring; the firmware management apparatus is further configured to: load plug-ins by using a preset dependency analysis engine during runtime of the target firmware, and generate a software bill of materials file of the plug-ins, the software bill of materials file being used to maintain an association relationship between the plug-ins and their dependencies; the operation execution module is specifically configured to: load and analyze the software bill of materials file, determine associated plug-ins having a dependency relationship with the target plug-in, and perform the target operation on the target plug-in in the plug-in pool according to the target plug-in, the associated plug-ins, and the dependency relationship.

17. An electronic device, comprising: includes: a memory for storing a computer program; a processor for implementing the steps of the firmware management method as claimed in any one of claims 1 to 15 when executing the computer program.

18. A computer-readable storage medium, characterized in that, The computer program is stored in the computer readable storage medium and is executed by the processor to implement the steps of the firmware management method as claimed in any one of claims 1 to 15.

19. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the firmware management method as claimed in any one of claims 1 to 15.

Images