Vehicle Linux container subsystem sharing method and related device thereof
Through V2X communication module and container virtualization technology, efficient and secure sharing of Linux container subsystems between vehicles is achieved, the problem of insufficient resource scheduling and allocation is solved, and the resource utilization rate and collaborative work ability of intelligent connected vehicles is improved.
Patent Information
- Application Number
- CN202510854625.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-24
- Publication Date
- 2025-08-05
AI Technical Summary
The existing V2X technology lacks a dynamic collaboration mechanism in the Internet of Vehicles environment, making it difficult to schedule and allocate resources according to actual needs, and the sharing support for computing resources and application services is relatively limited.
The V2X communication module realizes the connection between vehicles, obtains a list of available Linux container subsystems, performs authentication and permission checks, uses access tokens to share the computing resources and storage resources of the target Linux container subsystem, and introduces a flexible resource scheduling and allocation mechanism.
It improves resource utilization and collaborative work capabilities among vehicles, ensures the security and flexibility of resource sharing, and supports a variety of application scenarios such as data processing and image recognition.
Smart Images
Figure CN120434604A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of automobile technology, and in particular to a method for sharing a Linux container subsystem of a vehicle and related devices. Background Art
[0002] With the development of intelligent connected vehicles, vehicle-to-everything (V2X) communication is becoming increasingly important. V2X technologies encompass vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and vehicle-to-network (V2N) communications. These communication methods enable vehicles to exchange information in real time, improving traffic safety and efficiency. However, existing V2X technologies primarily focus on information sharing and collaborative decision-making, with limited support for sharing computing resources and application services. Container virtualization, on the other hand, allows multiple isolated Linux system instances to run on a single host operating system. This technology efficiently utilizes hardware resources and provides a flexible application deployment environment. However, existing container virtualization technologies lack dynamic collaboration mechanisms in connected vehicle environments, making it difficult to schedule and allocate resources based on actual needs. Summary of the Invention
[0003] The present application provides a vehicle Linux container subsystem sharing method and related devices, which are used to combine V2X technology and container virtualization technology to achieve efficient and secure sharing of Linux container subsystems between vehicles, so as to improve resource utilization and collaborative working capabilities.
[0004] In view of this, the first aspect of the present application provides a vehicle Linux container subsystem sharing method, comprising:
[0005] When resources are insufficient, the first vehicle obtains a list of available Linux container subsystems broadcast by the second vehicle; wherein the first vehicle establishes a connection with the second vehicle via a V2X communication module;
[0006] The first vehicle determines whether the required target Linux container subsystem exists in the list of available Linux container subsystems, and if so, sends a sharing request to the second vehicle to obtain an access token;
[0007] The first vehicle uses the access token to access the target Linux container subsystem of the second vehicle through the V2X communication module, and uses the computing resources and storage resources of the target Linux container subsystem to perform the target task.
[0008] Optionally, the method further includes:
[0009] The second vehicle authenticates the identity of the first vehicle and generates an access token after the authentication is passed; wherein, when the first vehicle and the second vehicle are vehicles of different brands, the first vehicle and the second vehicle establish cross-brand mutual trust by accessing the joint identity authentication platform of the automobile enterprise alliance.
[0010] Optionally, the first vehicle determining whether a required target Linux container subsystem exists in the list of available Linux container subsystems includes:
[0011] The first vehicle determines whether there is a target Linux container subsystem in the available Linux container subsystem list that has computing resources and storage resources that meet the target task and is compatible with the operating system and application of the first vehicle.
[0012] Optionally, the access token includes access permission information and access time information.
[0013] Optionally, the method further includes:
[0014] The second vehicle monitors resource usage of the target Linux container subsystem in real time;
[0015] Track the target tasks being run by the target Linux container subsystem in real time, and if any abnormal tasks are detected, destroy the abnormal tasks; if any tasks that have not responded for more than a preset time are detected, release the relevant resources;
[0016] The access operation of the first vehicle to the target Linux container subsystem is recorded in real time, and whether there is a security risk is detected.
[0017] Optionally, the method further includes:
[0018] The first vehicle requests the second vehicle to increase or decrease resource allocation according to the status of the target task and resource usage.
[0019] Optionally, the method further includes:
[0020] When the target mission is completed, the first vehicle sends a termination request to the second vehicle, and the second vehicle revokes the access token and releases related resources of the target Linux container subsystem.
[0021] A second aspect of the present application provides a vehicle Linux container subsystem sharing system, characterized by comprising: a first vehicle and a second vehicle; the first vehicle establishing a connection with the second vehicle via a V2X communication module;
[0022] The second vehicle is configured to broadcast a list of available Linux container subsystems to the first vehicle when resources are sufficient;
[0023] The first vehicle is configured to obtain a list of available Linux container subsystems broadcast by the second vehicle when resources are insufficient; determine whether the required target Linux container subsystem exists in the list of available Linux container subsystems, and if so, send a sharing request to the second vehicle to obtain an access token; use the access token to access the target Linux container subsystem of the second vehicle through the V2X communication module, and use the computing resources and storage resources of the target Linux container subsystem to perform a target task.
[0024] A third aspect of the present application provides an electronic device, the device comprising a processor and a memory;
[0025] The memory is used to store program code and transmit the program code to the processor;
[0026] The processor is used to execute the vehicle Linux container subsystem sharing method described in any one of the first aspects according to the instructions in the program code.
[0027] In a fourth aspect, the present application provides a computer-readable storage medium for storing program code. When the program code is executed by a processor, the vehicle Linux container subsystem sharing method described in any one of the first aspects is implemented.
[0028] It can be seen from the above technical solutions that this application has the following advantages:
[0029] The vehicle Linux container subsystem sharing method provided in this application enables vehicles with weaker computing capabilities to complete complex tasks with the help of other vehicles' powerful computing resources by sharing LXC subsystem resources, making full use of the idle resources of each vehicle and improving overall resource utilization. It also enables information exchange and resource sharing between vehicles through V2X communication technology, thereby improving the collaborative working capabilities of intelligent connected vehicles.
[0030] Furthermore, this application introduces an authentication and permission checking mechanism to ensure that only authorized vehicles can access and share the LXC subsystem, preventing unauthorized access; using temporary access tokens for resource sharing, effectively controlling access time and scope, and further improving system security. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0032] Figure 1 A schematic flow chart of a method for sharing a Linux container subsystem of a vehicle provided in an embodiment of the present application;
[0033] Figure 2 A schematic diagram of a Linux container subsystem sharing system for a vehicle provided in an embodiment of the present application;
[0034] Figure 3 Another flowchart of a method for sharing a Linux container subsystem of a vehicle provided in an embodiment of the present application;
[0035] Figure 4 A schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0036] In order to help those skilled in the art better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of this application.
[0037] For easier understanding, please refer to Figure 1 , an embodiment of the present application provides a vehicle Linux container subsystem sharing method, comprising:
[0038] Step 110: When the first vehicle is short of resources, the first vehicle obtains a list of available Linux container subsystems broadcast by the second vehicle; wherein the first vehicle establishes a connection with the second vehicle via a V2X communication module;
[0039] Both the first and second vehicles are equipped with a V2X communication module, including one or more Linux container subsystems (LXC subsystems). The first vehicle establishes a connection with the second vehicle via the V2X communication module. The V2X communication module can utilize various communication technologies, such as 5G and DSRC (Dedicated Short Range Communication), and supports V2V, V2I, V2P, and V2N communication protocols for information exchange between vehicles.
[0040] When the first vehicle and the second vehicle have sufficient resources, they can broadcast their own available LXC subsystem lists to the vehicles they are connected to. When the first vehicle has insufficient resources, it obtains the available Linux container subsystem list broadcast by the second vehicle.
[0041] It should be noted that the first or second vehicle will provide authorized LXC subsystems to other vehicles based on their own security policies and data privacy requirements. LXC subsystems involving sensitive data or privacy will not be shared. The LXC subsystem operates in an independent security domain (such as ARM TrustZone) and prohibits access to the vehicle's critical bus (CAN). Sharing functions must pass functional safety certification to ensure that they do not affect the safe operation of the vehicle itself and are limited to sharing between vehicles within the same jurisdiction (for example, vehicles in China are prohibited from providing resources to vehicles outside the country). Sensitive vehicle data (such as geographic location) must be kept private, and operation logs are recorded on the blockchain to clarify accountability and facilitate traceability.
[0042] Step 120: The first vehicle determines whether the required target Linux container subsystem exists in the list of available Linux container subsystems. If so, the first vehicle sends a sharing request to the second vehicle to obtain an access token.
[0043] After obtaining the list of available Linux container subsystems, the first vehicle determines whether there is a Linux container subsystem in the list that meets the computing and storage resource requirements of the target task. If multiple Linux container subsystems meet the requirements, the first vehicle selects a Linux container subsystem with sufficient processing power and low latency based on the real-time requirements of its own task. Furthermore, a certified Linux container subsystem that meets security standards is selected as the target Linux container subsystem to ensure data and communication security. The target Linux container subsystem must be compatible with the first vehicle's operating system and applications.
[0044] After the first vehicle determines that the required target Linux container subsystem exists in the list of available Linux container subsystems, it sends a sharing request to the second vehicle to obtain sharing authorization for the target Linux container subsystem. After receiving the sharing request, the second vehicle authenticates the first vehicle and generates an access token after the verification is passed. The first and second vehicles can authenticate each other through encrypted digital certificates. Each vehicle has a unique certificate to prove its identity. V2X communication security is ensured by encryption protocols. Vehicles of different brands need to access the joint identity authentication platform of the automobile enterprise alliance to achieve cross-brand mutual trust. After the identity authentication is passed, the second vehicle will generate a temporary access token, which includes access permission information and access time information (used to limit the access time). The access token is set with a validity period, such as the access token validity period ≤ 10 seconds.
[0045] Step 130: The first vehicle uses the access token to access the target Linux container subsystem of the second vehicle through the V2X communication module, and uses the computing resources and storage resources of the target Linux container subsystem to perform the target task.
[0046] After obtaining the access token, the first vehicle uses it to access the second vehicle's target Linux container subsystem via the V2X communication module. It then uses the target Linux container subsystem's computing and storage resources to perform its target task (such as image recognition or path planning). The first vehicle can manage its target Linux container subsystem through the interface, including starting, stopping, and monitoring its operating status. Resource usage can be viewed in real time and adjusted as necessary. Specifically, the first vehicle can request an increase or decrease in resource allocation from the second vehicle based on the target task's status and resource usage. When the first vehicle completes its target task or no longer requires certain resources, it can proactively release those resources.
[0047] Furthermore, after sharing the target Linux container subsystem with the first vehicle, the second vehicle can monitor the usage of the target Linux container subsystem in real time to ensure the rational use of resources.
[0048] Specifically, the second vehicle monitors the resource usage of the target Linux container subsystem in real time, including the usage of CPU, memory, and storage resources to ensure that system resource limits are not exceeded;
[0049] The second vehicle tracks the target tasks being run by the target Linux container subsystem in real time, including task progress, priority, and execution time. If any abnormal tasks are detected, they are destroyed; if any tasks that have not responded for more than a preset time are detected, the relevant resources are released;
[0050] The second vehicle records the first vehicle's access operations to the target Linux container subsystem in real time and detects whether there are security risks, such as unauthorized access attempts or data leakage risks. If a security risk is detected, the first vehicle's access rights to the target Linux container subsystem are terminated.
[0051] Furthermore, when the target mission is completed, the first vehicle sends a termination request to the second vehicle, which revokes the access token, releases the relevant resources of the target Linux container subsystem, cleans up the relevant data and configuration, and ensures system security and resource recovery.
[0052] By sharing LXC subsystem resources, this application enables vehicles with weaker computing power to complete complex tasks with the help of other vehicles' powerful computing resources, fully utilizing the idle resources of each vehicle and improving overall resource utilization. The V2X communication module supports multiple communication technologies, ensuring stable and efficient communication in different environments. V2X communication technology enables information exchange and resource sharing between vehicles, improving the collaborative working capabilities of intelligent connected vehicles.
[0053] Furthermore, an authentication and permission checking mechanism is introduced to ensure that only authorized vehicles can access and share the LXC subsystem, preventing unauthorized access; temporary access tokens are used for resource sharing to effectively control access time and scope, further improving system security.
[0054] Please refer to Figure 2 , an embodiment of the present application provides a vehicle Linux container subsystem sharing system, comprising: a first vehicle and a second vehicle; the first vehicle establishes a connection with the second vehicle via a V2X communication module;
[0055] The second vehicle is configured to broadcast a list of available Linux container subsystems to the first vehicle when resources are sufficient;
[0056] The first vehicle is configured to obtain a list of available Linux container subsystems broadcast by the second vehicle when resources are insufficient; determine whether the required target Linux container subsystem exists in the list of available Linux container subsystems, and if so, send a sharing request to the second vehicle to obtain an access token; use the access token to access the target Linux container subsystem of the second vehicle through the V2X communication module, and use the computing resources and storage resources of the target Linux container subsystem to perform the target task.
[0057] Please refer to Figure 3 ,In the initialization phase, the first vehicle (vehicle B) and the second vehicle (vehicle A) ,establish a connection through the V2X communication module. When the ,second vehicle has sufficient resources, it broadcasts its available LXC subsystem ,list to the first vehicle.
[0058] During the request phase, the first vehicle selects the required subsystem from the second vehicle's LXC subsystem list based on its own needs and sends a request. Based on its own security policies and data privacy requirements, the second vehicle will only provide authorized subsystems to the first vehicle. LXC subsystems involving sensitive data or privacy will not be shared. Therefore, when selecting an LXC subsystem, the first vehicle needs to confirm whether the required LXC subsystem is within the authorization scope of the second vehicle. The first vehicle evaluates the computing resource and storage resource requirements of its own tasks and selects an LXC subsystem that can meet these requirements. It can also select an LXC subsystem with sufficient processing power and low latency based on the real-time requirements of its own tasks; and selects an LXC subsystem that is certified and meets security standards to ensure the security of data and communications, and selects an LXC subsystem that is compatible with the operating system and applications of the first vehicle to obtain the final target LXC subsystem.
[0059] During the authentication and authorization phase, after receiving the sharing request from the first vehicle, the second vehicle performs identity verification and permission checks. The first and second vehicles can authenticate each other using encrypted digital certificates, with each vehicle possessing a unique certificate to verify its identity. Encryption protocols ensure the security of V2X communications, and vehicles of different brands must connect to the joint identity authentication platform of the OEM alliance to achieve cross-brand mutual trust. If authentication is successful, the second vehicle generates a temporary access token and sends it to the first vehicle. This token contains access permission information and access time information.
[0060] During the sharing phase, the first vehicle uses a temporary access token to access the target LXC subsystem of the second vehicle through the V2X communication module. The second vehicle shares the computing resources, storage resources, etc. of the target LXC subsystem with the first vehicle.
[0061] During the monitoring and management phase, the second vehicle monitors the usage of the target LXC subsystem in real time to ensure the rational use of resources. Specifically, the second vehicle monitors the usage of resources such as CPU, memory, and storage by the shared target LXC subsystem in real time to ensure that the system resource limit is not exceeded; the second vehicle tracks the tasks running by the target LXC subsystem in real time, including task progress, priority, and execution time, and detects abnormal tasks or tasks that have not responded for a long time, and will take measures such as release and destruction. The second vehicle records all access operations of the first vehicle to the target LXC subsystem to detect potential security threats, such as unauthorized access attempts or data leakage risks. The second vehicle supports the first vehicle in requesting more subsystem resources or releasing resources that are no longer needed. The first vehicle can dynamically adjust the use of the target LXC subsystem as needed:
[0062] 1. Application phase: The first vehicle applies to the second vehicle for the use of a specific LXC subsystem based on mission requirements, specifying the required resource type, computing power, storage space, etc.
[0063] 2. Management phase: The first vehicle can manage the target LXC subsystem it uses through the interface, including starting, stopping, and monitoring the operating status. It can view resource usage in real time and make necessary resource adjustments.
[0064] 3. Resource allocation and adjustment: Based on the task status and resource usage, the first vehicle can request to increase or decrease resource allocation.
[0065] 4. Resource release: When the first vehicle completes its mission or no longer needs certain resources, it can actively release these resources.
[0066] In the termination phase, when the first vehicle no longer needs to use the target LXC subsystem, it sends a termination request to the second vehicle. The second vehicle revokes the temporary access token, cleans up related data and configurations, and ensures system security and resource recovery.
[0067] By sharing LXC subsystem resources, this application enables vehicles with less computing power to leverage the powerful computing resources of other vehicles to complete complex tasks, fully utilizing each vehicle's idle resources and improving overall resource utilization. This application also provides a flexible resource scheduling and allocation mechanism, enabling vehicles to dynamically request and share LXC subsystems from other vehicles based on actual needs. This supports a variety of application scenarios, such as data processing, image recognition, and path planning, to meet the needs of different tasks. This application introduces an authentication and permission checking mechanism to ensure that only authorized vehicles can access and share the LXC subsystem, preventing unauthorized access. The use of temporary access tokens for resource sharing effectively controls access time and scope, further enhancing system security. The V2X communication module in this application supports multiple communication technologies (such as 5G and DSRC), ensuring stable and efficient communication in diverse environments. V2X communication technology enables information exchange and resource sharing between vehicles, enhancing the collaborative capabilities of intelligent connected vehicles.
[0068] In summary, this application achieves efficient and secure sharing of LXC subsystems between vehicles by combining V2X communication technology and container virtualization technology, significantly improving resource utilization and collaborative working capabilities, and has broad application prospects.
[0069] Please refer to Figure 4 , an embodiment of the present application further provides an electronic device, the device including a processor 210 and a memory 220;
[0070] The memory 220 is used to store program codes and transmit the program codes to the processor 210;
[0071] The processor 210 is configured to execute the vehicle Linux container subsystem sharing method in the aforementioned method embodiment according to instructions in the program code.
[0072] An embodiment of the present application also provides a computer-readable storage medium, which is used to store program code. When the program code is executed by a processor, it implements the vehicle Linux container subsystem sharing method in the aforementioned method embodiment.
[0073] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working process of the system described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.
[0074] In the specification of this application and the above-mentioned drawings, the terms "first," "second," "third," "fourth," etc. (if any) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus that includes a series of steps or elements is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, method, product, or apparatus.
[0075] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or plural.
[0076] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0077] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.
[0078] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0079] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for executing all or part of the steps of the method described in each embodiment of the present application through a computer device (which can be a personal computer, server, or network device, etc.). The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (full name: Read-Only Memory, English abbreviation: ROM), random access memory (full name: Random Access Memory, English abbreviation: RAM), disk or optical disk, and other media that can store program code.
[0080] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims
1. A vehicle Linux container subsystem sharing method, characterized in that: include: When resources are insufficient, the first vehicle obtains a list of available Linux container subsystems broadcast by the second vehicle; wherein the first vehicle establishes a connection with the second vehicle via a V2X communication module; The first vehicle determines whether the required target Linux container subsystem exists in the list of available Linux container subsystems, and if so, sends a sharing request to the second vehicle to obtain an access token; The first vehicle uses the access token to access the target Linux container subsystem of the second vehicle through the V2X communication module, and uses the computing resources and storage resources of the target Linux container subsystem to perform the target task.
2. The vehicle Linux container subsystem sharing method according to claim 1, characterized in that: The method further comprises: The second vehicle authenticates the identity of the first vehicle and generates an access token after the authentication is passed; wherein, when the first vehicle and the second vehicle are vehicles of different brands, the first vehicle and the second vehicle establish cross-brand mutual trust by accessing the joint identity authentication platform of the automobile enterprise alliance.
3. The vehicle Linux container subsystem sharing method according to claim 1, characterized in that: The first vehicle determines whether a required target Linux container subsystem exists in the list of available Linux container subsystems, including: The first vehicle determines whether there is a target Linux container subsystem in the available Linux container subsystem list that has computing resources and storage resources that meet the target task and is compatible with the operating system and application of the first vehicle.
4. The vehicle Linux container subsystem sharing method according to claim 1 or 3, characterized in that: The access token includes access permission information and access time information.
5. The vehicle Linux container subsystem sharing method according to claim 1, characterized in that: The method further comprises: The second vehicle monitors resource usage of the target Linux container subsystem in real time; Track the target tasks being run by the target Linux container subsystem in real time, and if any abnormal tasks are detected, destroy the abnormal tasks; if any tasks that have not responded for more than a preset time are detected, release the relevant resources; The access operation of the first vehicle to the target Linux container subsystem is recorded in real time, and whether there is a security risk is detected.
6. The vehicle Linux container subsystem sharing method according to claim 1, characterized in that: The method further comprises: The first vehicle requests the second vehicle to increase or decrease resource allocation according to the status of the target task and resource usage.
7. The vehicle Linux container subsystem sharing method according to claim 1, characterized in that: The method further comprises: When the target mission is completed, the first vehicle sends a termination request to the second vehicle, and the second vehicle revokes the access token and releases related resources of the target Linux container subsystem.
8. A vehicle Linux container subsystem sharing system, characterized in that: include: A first vehicle and a second vehicle; the first vehicle establishes a connection with the second vehicle via a V2X communication module; The second vehicle is configured to broadcast a list of available Linux container subsystems to the first vehicle when resources are sufficient; The first vehicle is configured to, when resources are insufficient, obtain a list of available Linux container subsystems broadcast by the second vehicle; determine whether a desired target Linux container subsystem exists in the list of available Linux container subsystems, and if so, send a sharing request to the second vehicle to obtain an access token; Using the access token, access the target Linux container subsystem of the second vehicle through the V2X communication module, and use the computing resources and storage resources of the target Linux container subsystem to perform the target task.
9. An electronic device, characterized in that: The device includes a processor and a memory; The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the vehicle Linux container subsystem sharing method according to any one of claims 1 to 7 according to the instructions in the program code.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium is used to store program code, and when the program code is executed by a processor, the vehicle Linux container subsystem sharing method according to any one of claims 1 to 7 is implemented.