APEX file processing method, electronic equipment and computer program product

Abstract

The invention provides an APEX file processing method, electronic equipment and a computer program product. The method comprises the steps that under the condition that a first container system calls a mapping device driver to request to create a target APEX file in the kernel, whether the target APEX file exists in the kernel or not is inquired, and the first container system belongs to the multi-container system. And under the condition that it is queried that the target APEX file exists in the kernel, unloading the target APEX file and a circulating device used for activating the target APEX file from the kernel based on the first container system, and re-creating the target APEX file and the circulating device in the kernel. The problem that the APEX technology cannot be suitable for a multi-container system is at least solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for processing APEX files, an electronic device, and a computer program product. Background Technology

[0002] With the development of computer technology, many users install multiple operating systems on a single mobile device to meet their specific needs. Among these, implementing different operating systems based on container technology is currently a mainstream approach. That is, each container corresponds to an operating system (also known as a container system), and these container systems share the mobile device's kernel.

[0003] Android Pony Express (APEX) is a container format introduced by the Android system for updating and upgrading individual modules. While current multi-container systems share the mobile device's kernel, they do not support sharing APEX files within the kernel. In other words, APEX technology is not suitable for multi-container systems. Summary of the Invention

[0004] The purpose of this application is to provide an APEX file processing method, electronic device, and computer program product, which can at least solve the problem that APEX technology cannot be applied to multi-container systems.

[0005] To achieve at least the above objectives, the embodiments of this application are implemented as follows:

[0006] Firstly, a method for processing APEX files is provided, applicable to multi-container systems, including:

[0007] In the case where the first container system calls the mapped device driver to request the creation of a target APEX file in the kernel, it queries whether the target APEX file already exists in the kernel, and the first container system belongs to the multi-container system;

[0008] If the target APEX file already exists in the kernel, the target APEX file and the loop device used to activate the target APEX file are unloaded from the kernel based on the first container system, and the target APEX file and the loop device are recreated in the kernel.

[0009] In a second aspect, embodiments of this application provide an electronic device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the method described in the first aspect.

[0010] Thirdly, a computer program product is provided, the computer program product including a computer-readable storage medium storing a computer program operable to cause a computer to perform the method described in the first aspect.

[0011] In this embodiment, when the first container system calls the mapped device driver to request the creation of the target APEX file in the kernel, it first checks whether the target APEX file already exists in the kernel. If it does, it indicates that another container system has already created the target APEX file in the kernel. In this case, the first container system unloads the target APEX file and the loop device used to activate the target APEX file from the kernel to ensure that the other container systems that preemptively created it still consider themselves the installer of the target APEX file. Then, the first container system recreates the target APEX file and the loop device in the kernel, so that the first container system also considers itself the installer of the target APEX file. This achieves the effect that the target APEX file can be shared by the first container system and the other container systems that preemptively created it, which is equivalent to virtualizing the target APEX file in the kernel. The solution of this embodiment makes APEX technology applicable to multi-container systems. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of the first flowchart of the APEX file processing method according to an embodiment of this application.

[0014] Figure 2 This is a schematic diagram of a second flowchart of the APEX file processing method according to an embodiment of this application.

[0015] Figure 3 This is a schematic diagram of the third process of processing APEX files according to an embodiment of this application.

[0016] Figure 4 This is a schematic diagram of the structure of the APEX file processing device according to an embodiment of this application.

[0017] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0018] As mentioned earlier, while existing multi-container systems share the kernel of mobile devices, they do not support the sharing of APEX files within the kernel. This makes APEX technology unsuitable for mobile devices operating in multi-container systems, causing inconvenience for users updating their systems. Therefore, this application aims to propose an APEX file processing scheme that enables the sharing of APEX files across multiple container systems without altering the container system itself.

[0019] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0020] One embodiment of this application proposes a method for processing APEX files, applicable to a multi-container system. Figure 1 This is a flowchart illustrating the processing method, which may include the following steps:

[0021] S102, if the first container system calls the mapped device driver to request the creation of the target APEX file in the kernel, query whether the target APEX file already exists in the kernel.

[0022] In existing multi-container systems, each container system only uses the APEX file installed on its own mobile device kernel. This means that once an APEX file for a certain function is created by one container system, it cannot be used by other container systems.

[0023] In this embodiment, the first container system is a multi-container system. After the first container system starts running, if it needs to use the target APEX file, it must create the target APEX file in its kernel. Correspondingly, the target APEX file may have already been created by other container systems. Therefore, the first container system needs to be virtualized so that all container systems that need to use the target APEX file consider themselves the sole user of the target APEX file.

[0024] S104, if the target APEX file already exists in the kernel, unload the target APEX file and the loop device used to activate the target APEX file from the kernel based on the first container system, and recreate the target APEX file and the loop device in the kernel.

[0025] A loop device, also known as a block device, is a technology that simulates a block device. Once a file is simulated as a block device, it can be used like a disk or optical disc. In current technology, when any container system creates an APEX file in the kernel, it also needs to create a corresponding loop device to activate that APEX file.

[0026] It should be understood that in this embodiment, finding that the target APEX file already exists in the kernel means that another container system has already created the target APEX file in the kernel. For ease of distinction, this document defines the other container system that created the target APEX file before the first container system as the second container system. That is, the second container system is the installer of the target APEX file. In this case, the first container system needs to unload the target APEX file and the loop device used to activate the target APEX file from the kernel, while the second container system still considers itself to be the installer of the target APEX file. Then, the first container system calls the device mapping driver (Device-Mapper, DM) in the kernel to recreate the target APEX file and the corresponding loop device in the kernel, so that the first container system also considers itself to be the installer of the target APEX file. At this point, both the first and second container systems can use the target APEX file normally through the loop device, thereby realizing the virtualized deployment of the target APEX file.

[0027] Furthermore, in this embodiment, the absence of the target APEX file in the kernel means that no other container system has preemptively created the target APEX file in the kernel. In this case, the first container system can directly create the target APEX file and the corresponding loop device in the kernel by calling the internal DM. At this time, the first container system considers itself to be the installer of the target APEX file and can use the target APEX file normally through the loop device.

[0028] The above explains the principles of virtualization deployment from the perspective of creating the target APEX file. In the subsequent application of the target APEX file, when the first container system updates the target APEX file, it is also necessary to consider how the second container system should synchronize the data state of the target APEX file.

[0029] Here, this embodiment provides a synchronization method. Once a write operation is performed on the target APEX file in the kernel based on the first container system (all updates are write operations), the write operation needs to be notified to all other container systems in the multi-container system, so that the second container systems in all other container systems can perform write operations on the target APEX file in the kernel, thereby enabling the second container systems to synchronize and update the data status of the target APEX file with the first container system.

[0030] For example: A second container system creates a version 1 target APEX file in the kernel. At this point, the upper-layer applications of the second container system assume the target APEX file is in the version 1 data state. Later, an upper-layer application of the first container system also needs to use the target APEX file, causing the first container system to unload and reinstall the version 1 target APEX file and its corresponding circular device from the kernel. At this point, both the first and second container systems' upper-layer applications assume the target APEX file is in the version 1 data state. When the first container system's upper-layer application discovers that the target APEX file has a version 2, the first container system independently initiates an update (write operation) on the target APEX file in the kernel, iterating the target APEX file to the version 2 data state. At this point, the second container system's upper-layer application is unaware that the target APEX file has been updated by the first container system and still believes the target APEX file is in the version 1 data state. However, the first container system subsequently sends a write operation notification of this update to all other container systems, causing the second container system, upon receiving the notification, to re-initiate an update (write operation) on the target APEX file in the kernel to ensure that its own upper-layer applications also believe the target APEX file is in the version 2 data state.

[0031] It should be noted that the second container system in this embodiment is not limited to one. When there are multiple second container systems, to avoid conflicts caused by simultaneous write operations on the target APEX file, a method of passing write operation notifications to other container systems can be adopted. That is, according to the container system order set for multiple container systems, the write operation is notified to one of the other container systems in the multiple container systems. This allows the other container system that receives the notification to notify the next other container system in the container system order if it is not the second container system, or if it is the second container system and has already performed a write operation on the target APEX file in the kernel, and so on, until all other container systems have received the write operation notification.

[0032] For example, in this embodiment, the startup order of container systems in a multi-container system can be used as the container system sorting. Assuming that the startup order of the other container systems besides the first container system is container system A → container system B → container system C → container system D, then the container system sorting is also container system A → container system B → container system C → container system D.

[0033] Further defining container system C as the second container system, after the first container system performs a write operation on the target APEX file, it needs to send the write operation notification to container system B in sequence. After receiving the notification, container system B, since it does not need to use the target APEX file, directly sends the notification to container system C in sequence. After receiving the write operation notification, container system C performs the same write operation on the target APEX file to maintain data state synchronization, and then sends the notification to container system D in sequence after the write operation is completed. After receiving the write operation notification, container system D, since it does not need to use the target APEX file, can either end the notification sending by being the last container system in the sorting, or container system D can loop through the notification to resend it back to container system A. Container system A will not send any more notifications after receiving the write operation notification for the second time.

[0034] It should be understood that the container system sorting scheme in this embodiment is not unique and is not specifically limited here. For example, as another feasible implementation, the container systems can also be sorted according to their names, such as container systems with names starting with A being sorted before those with names starting with B, and so on, and container systems with names starting with Y being sorted before those with names starting with Z.

[0035] Based on the write operation transitive notification described above, each container system does not need to consider whether other container systems need to use the target APEX file. If a container system that receives the notification needs to use the target APEX file, it can perform the write operation itself. In addition, the notification is sent to the next container system only after the write operation is completed. This ensures that when there are multiple second container systems, they will not initiate write operations on the target APEX file at the same time, effectively avoiding the problem of target APEX file update conflicts.

[0036] The following describes the process of creating APEX file virtualization.

[0037] Taking the target APEX file as an example, this embodiment can divide virtualization creation into the target APEX file creation stage and the target APEX file application stage.

[0038] I. The creation phase of the target APEX file

[0039] The core of this phase is that after the first container system starts, if it needs to create a target APEX file in the kernel, it first needs to determine if any other container system has already created the target APEX file in the kernel. If the target APEX file has already been created in the kernel, it needs to be uninstalled and recreated to achieve the goal of a normal target APEX file. The specific process is as follows: Figure 2 As shown, it includes:

[0040] Step A01: During the startup process, the first container system needs to use the target APEX file. It calls the DM to create a circular device for the target APEX file. This circular device corresponds to the package name of the target APEX file.

[0041] Step A02: During the creation of the loop device, the first container system queries the package name of the target APEX file through the kernel's red-black tree.

[0042] The red-black tree is created and managed by the kernel during DM initialization to record the package names of all APEX files created by the kernel. Therefore, if the query finds a match, it can be determined that the target APEX file already exists in the kernel; if the query fails to find a match, it can be determined that the target APEX file does not exist in the kernel.

[0043] Step A03: If the target APEX file does not exist in the kernel, it means that the first container system will be the first installer of the target APEX file. The target APEX file and the corresponding loop device can be added directly to the kernel based on DM.

[0044] Step A04: If the target APEX file does not exist in the kernel, it means that a second container system has already created the target APEX file and the corresponding loop device in the kernel. At this time, unload the target APEX file and the loop device from the kernel, and then add the target APEX file and the corresponding loop device back into the kernel based on DM as in step A03.

[0045] It's important to note that APEX files are relatively small in size, and the time required to uninstall and reinstall the target APEX file and its corresponding loop device is negligible and does not affect the normal use of the target APEX file by the second container system. Furthermore, uninstalling the target APEX file and loop device previously created by the second container system does not affect the normal operation of the second container system for the target APEX file. This is because the second container system adds the target APEX file and loop device to the components of the upper-layer application when it is created, and the upper-layer application already runs the target APEX file through its own components.

[0046] It should be noted that, in addition to the method of uninstalling the target APEX file, this embodiment can also be replaced by introducing a namespace in the kernel.

[0047] For example, if the target APEX files created by the first and second container systems use different namespaces to define their package names, two target APEX files that originally had the same functionality might be considered different APEX files by both container systems due to their different package names, and thus both might be used by them. However, this is not a suitable solution for sharing APEX files. The fact that a single APEX file already needs to be distinguished due to different package names makes the mapping more complex and consumes more memory resources.

[0048] II. Application Stage of the Target APEX File

[0049] This phase involves operations performed by the first and second container systems on the target APEX file. The specific process is as follows: Figure 3 As shown, it includes:

[0050] Step B01: The first container system initiates a target operation against the target APEX file.

[0051] Specifically, the first container system needs to call the ioctl function on the target APEX file through DM to initiate the target operation. The ioctl function carries operation parameters, and DM will automatically parse the meaning of the operation.

[0052] Step B02: The table determines whether the target operation is a read or write operation based on the operation parameters in the ioctl function.

[0053] Step B03: If the target operation is a read operation, then read the target APEX file through the circular device of the target APEX file in the kernel to obtain the corresponding information.

[0054] Step B04: If the target operation is a write operation, then the write operation is performed on the target APEX file through the circular device of the target APEX file in the kernel, and after completion, the write operation is relayed to all other container systems.

[0055] Step B05: Upon receiving the write operation, the second container system calls DM to initiate an update process for the target APEX file. In other words, the second container system executes steps B01 to B04 again.

[0056] It should be understood that performing the target operation again in the second container system will not change the data state of the target APEX file in the kernel, but the components of the upper-layer application of the second container system will update the data state of the target APEX file.

[0057] Corresponding to Figure 4 The method shown in this application is another embodiment of an APEX file processing apparatus. Figure 4This is a structural diagram of the 400 processor, including:

[0058] The query module 410 queries whether the target APEX file already exists in the kernel when the first container system in a multi-container system calls the mapping device driver to request the creation of the target APEX file in the kernel.

[0059] Execution module 420, upon finding that the target APEX file already exists in the kernel, unloads the target APEX file and the loop device used to activate the target APEX file from the kernel based on the first container system, and recreates the target APEX file and the loop device in the kernel.

[0060] In this embodiment, when the first container system calls the mapped device driver to request the creation of a target APEX file in the kernel, the apparatus first checks whether the target APEX file already exists in the kernel. If it exists, it indicates that another container system has already created the target APEX file in the kernel. In this case, the first container system unloads the target APEX file and the loop device used to activate the target APEX file from the kernel to ensure that the other container systems that preemptively created the file still consider themselves the installer of the target APEX file. Then, the first container system recreates the target APEX file and the loop device in the kernel, so that the first container system also considers itself the installer of the target APEX file. This achieves the effect that the target APEX file can be shared by the first container system and the other container systems that preemptively created the file, which is equivalent to virtualizing and deploying the target APEX file in the kernel. The apparatus of this embodiment makes APEX technology applicable to multiple container systems.

[0061] Optionally, if the target APEX file does not exist in the kernel, the execution module 420 may also create the target APEX file and the loop device APEX for activating the target APEX file in the kernel based on the first container system.

[0062] In the apparatus of this embodiment, when the first container system calls the mapped device driver to request the creation of a target APEX file in the kernel, it first checks whether the target APEX file already exists in the kernel. If it exists, it indicates that another container system has already created the target APEX file in the kernel. In this case, the first container system unloads the target APEX file and the loop device used to activate the target APEX file from the kernel to ensure that the other container systems that preemptively created the file still consider themselves the installer of the target APEX file. Then, the first container system recreates the target APEX file and the loop device in the kernel, so that the first container system also considers itself the installer of the target APEX file. This achieves the effect that the target APEX file can be shared by the first container system and the other container systems that preemptively created the file, which is equivalent to virtualizing and deploying the target APEX file in the kernel. The apparatus of this embodiment enables APEX technology to be applied to multiple container systems.

[0063] Optionally, after the first container system performs a write operation on the target APEX file in the kernel, the execution module 420 also notifies all other container systems in the multi-container system of the write operation, so that the second container system in all other container systems performs the write operation on the target APEX file in the kernel, thereby enabling the second container system to synchronously update the data status of the target APEX file in line with the first container system. The second container system refers to other container systems that previously created the target APEX file and the loop device in the kernel.

[0064] Optionally, the execution module 420 notifies all other container systems in the multi-container system of the write operation, including: notifying one other container system in the multi-container system of the write operation according to the container system order set for the multi-container system, such that if the other container system that receives the notification is not the second container system, or if it is the second container system and has already performed the write operation on the target APEX file in the kernel, it notifies the next other container system in the corresponding container system order of the write operation, until all other container systems have received the notification of the write operation.

[0065] Optionally, the container system order of the multi-container system is consistent with the container system startup order in the multi-container system.

[0066] Optionally, the kernel is configured with a red-black tree, which is used to record the package names of all APEX files created by the kernel; the query module 410 queries whether the target APEX file already exists in the kernel, including: querying the red-black tree for the package name of the target APEX file; if the query is successful, determining that the target APEX file already exists in the kernel; or if the query is unsuccessful, determining that the target APEX file does not exist in the kernel.

[0067] Optionally, after unloading the target APEX file and the loop device used to activate the target APEX file from the kernel, the execution module 420 also removes the package name of the target APEX file from the red-black tree.

[0068] Optionally, the execution module 420 creates the target APEX file and the loop device in the kernel, including: calling the device mapping driver in the kernel to create the target APEX file and the loop device in the kernel.

[0069] It should be noted that the processing device in this embodiment can be used as... Figure 1 The execution body of the method shown is therefore able to achieve... Figure 1 The steps and functions of the method shown will not be repeated here.

[0070] Figure 5 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Please refer to it. Figure 5 At the hardware level, the electronic device includes a processor 510, and optionally also includes an internal bus 520, memory 530, and memory 540. The memory may include main memory, such as high-speed random-access memory (RAM), and may also include non-volatile memory, such as at least one disk storage device. Of course, the electronic device may also include other hardware required for business operations. At the software level, the electronic device is configured with a kernel running multiple container systems 550 (including at least a first container system and a second container system), where each container system can use hardware-level resources. Figure 1 The method shown can run as a whole in a multi-container system, or it can run individually in each container, or it can run separately in one or more containers. This article does not make any specific limitations.

[0071] The processor and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0072] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0073] The processor reads the corresponding computer program from non-volatile memory into memory and then executes it, forming the aforementioned APEX file processing device at the logical level. The processor executes the program stored in memory and specifically performs the following operations:

[0074] In a multi-container system, if the first container system calls the mapped device driver to request the creation of a target APEX file in the kernel, query whether the target APEX file already exists in the kernel.

[0075] If the target APEX file already exists in the kernel, the target APEX file and the loop device used to activate the target APEX file are unloaded from the kernel based on the first container system, and the target APEX file and the loop device are recreated in the kernel based on the first container system.

[0076] The above is as stated in this application. Figure 1The methods disclosed in the illustrated embodiments can be applied to or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in one or more embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in one or more embodiments of this application can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0077] Of course, in addition to software implementation, the electronic device of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0078] This application also proposes a computer program product, which includes a computer-readable storage medium storing a computer program operable to cause a computer to perform the following operations:

[0079] In a multi-container system, if the first container system calls the mapped device driver to request the creation of a target APEX file in the kernel, query whether the target APEX file already exists in the kernel.

[0080] If the target APEX file already exists in the kernel, the target APEX file and the loop device used to activate the target APEX file are unloaded from the kernel based on the first container system, and the target APEX file and the loop device are recreated in the kernel based on the first container system.

[0081] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this application should be included within the scope of protection of one or more embodiments of this application.

[0082] The systems, devices, and modules described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0083] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0084] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0085] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

Claims

1. A method for processing an APEX file, applied to a multi-container system, each container system in the multi-container system sharing a same kernel, the method comprising: in a case where a first container system in the multi-container system invokes a mapping device driver to request creation of a target APEX file in the kernel, querying whether the target APEX file already exists in the kernel; in a case where it is queried that the target APEX file already exists in the kernel, based on the first container system, unloading the target APEX file and a loop device for activating the target APEX file from the kernel, and re-creating the target APEX file and the loop device in the kernel.

2. The method of claim 1, further comprising: in a case where it is queried that the target APEX file does not exist in the kernel, based on the first container system, creating the target APEX file and the loop device for activating the target APEX file in the kernel.

3. The method of claim 1 or 2, after the target APEX file and the loop device are created in the kernel, the method further comprising: after a write operation is performed on the target APEX file in the kernel based on the first container system, notifying the write operation to all other container systems in the multi-container system, so that a second container system in all other container systems performs the write operation on the target APEX file in the kernel, thereby making the second container system follow the first container system to synchronously update a data state of the target APEX file, the second container system referring to other container systems that have previously created the target APEX file and the loop device in the kernel.

4. The method of claim 3, notifying the write operation to all other container systems in the multi-container system comprises: notifying the write operation to one other container system in the multi-container system according to a container system order set for the multi-container system, so that the other container system receiving the notification, in a case where it is not the second container system, or in a case where it is the second container system and has performed the write operation on the target APEX file in the kernel, notifies the write operation to a corresponding next other container system in the container system order until all other container systems receive the notification of the write operation.

5. The method of claim 4, the container system order of the multi-container system is consistent with a start-up order of container systems in the multi-container system.

6. The method of claim 1, the kernel is provided with a red-black tree, the red-black tree being used to record package names of all APEX files that have been created in the kernel; querying whether the target APEX file already exists in the kernel comprises: inquiring the package name of the target APEX file from the red-black tree; in a case where the inquiry hits, determining that the target APEX file already exists in the kernel; or In case of a query miss, it is determined that the target APEX file is not present in the kernel.

7. The method of claim 6, After offloading the target APEX file and a loop device for activating the target APEX file from the kernel, the method further comprises: deleting the package name of the target APEX file from the red-black tree.

8. The method of any one of claims 1 to 7, creating the target APEX file and the loop device in the kernel comprises: invoking a device mapping driver in the kernel to create the target APEX file and the loop device in the kernel.

9. An electronic device comprising a processor; and a memory configured to store computer-executable instructions that, when executed, cause the processor to perform the method of any one of claims 1-8.

10. A computer program product comprising a computer-readable storage medium storing a computer program operable to cause a computer to perform the method of any one of claims 1 to 8.

Images