Burned file making method and device, computer equipment and vehicle

Abstract

The invention discloses a burnt file making method and device, computer equipment and a vehicle, and belongs to the technical field of computer systems. Comprising the steps that a first system file is compiled to obtain a second system file, the first system file is a source code file of the vehicle-mounted Linux system, the second system file comprises a root mirror image file, and the root mirror image file is a mirror image file of a root directory in the vehicle-mounted Linux system; mounting the root mirror image file, and writing file tags into a plurality of files contained in the root mirror image file to obtain a third system file; and making a burning file of the vehicle-mounted chip based on the third system file. Thus, the corresponding file label is written on the file under the root directory in the manufacturing process of the burnt file, so that the vehicle-mounted Linux system does not need to write the file label on the file under the root directory in the first starting process, and the first starting time of the vehicle-mounted Linux system is shortened.

Description

Technical Field

[0001] This application relates to the field of computer system technology, and in particular to a method, apparatus, computer equipment, and vehicle for creating files for burning. Background Technology

[0002] The in-vehicle Linux system is a core underlying technology of in-vehicle electronic systems. It is an embedded operating system based on the Linux kernel. Currently, in-vehicle infotainment systems, autonomous driving systems, and other applications are mainly developed and implemented based on the Linux system. SELinux (Security-Enhanced Linux) is a security enhancement component for in-vehicle Linux systems. It is independent of the core functions of the Linux kernel and can be loaded as a module or compiled into the kernel to run on the in-vehicle embedded Linux, protecting critical resources in in-vehicle scenarios.

[0003] SELinux primarily defines security identifiers for all processes, files, and kernel data structures through security policy files. It explicitly defines the access methods supported by the accessed objects and specifies the legal access methods for processes to these objects. In other words, it defines corresponding access rules for each file and process to clarify who can access whom and what operations can be performed (e.g., reading or executing a file). Because SELinux identifies files through file tags, determining whether a process can access a file is based on its file tags. In this context, during the initial startup of a vehicle after it leaves the factory, the vehicle powers on the onboard chip, allowing the chip to run the onboard Linux system. Based on this principle, during the initial startup of the onboard Linux system, write operations are needed to write corresponding file tags to all files in the system.

[0004] However, the process of writing file tags requires traversing the entire file system and performing write operations on each file, which makes the entire tagging process very time-consuming. This will affect the boot time of the in-vehicle Linux system, and consequently lengthen the boot time of the corresponding systems in the vehicle (such as the in-vehicle infotainment system, autonomous driving system, etc.). Summary of the Invention

[0005] This application provides a method, apparatus, computer device, vehicle, and storage medium for creating burnable files. During the file creation process, appropriate file tags can be written to files that require them. This eliminates the need for writing file tags to the files in the file system during the initial boot of the vehicle's Linux system after the file has been burned to the vehicle's onboard chip. This saves time spent writing file tags during system startup, significantly reducing the initial boot time of the vehicle's Linux system. The technical solution includes the following:

[0006] Firstly, a method for creating a burnable file is provided, the method comprising: The first system file is compiled to obtain the second system file. The first system file refers to the source code file of the vehicle Linux system. The second system file includes a root image file, which is an image file of the root directory of the vehicle Linux system. The root directory contains files that need to be written with file tags during the startup process of the vehicle Linux system. Mount the root image file and write file tags for the multiple files contained in the root image file to obtain the third system file; Based on the aforementioned third system file, a programming file for the vehicle-mounted chip is created.

[0007] In this application, the source code files of the in-vehicle Linux system are first compiled to obtain a second system file. This second system file includes a root image file, which is an image of the root directory of the in-vehicle Linux system. Typically, during the boot process of an in-vehicle Linux system, file tags are written to the files in the root directory. Since the root image file has the same directory structure and format as the root directory, file tags can be written to the files under the root image file during the creation process. Next, the root image file is mounted, making all files under it accessible. Then, file tags are written to the multiple files contained in the root image file, resulting in a third system file—that is, a system file with pre-written file tags. Finally, the programming file for the in-vehicle chip is created based on the third system file. In this way, after the prepared burning file is burned to the vehicle chip, the vehicle Linux system will not need to write file tags to the files in the root directory during the first boot process. This saves the time spent writing file tags to each file during the system boot process, thus significantly reducing the first boot time of the vehicle Linux system. Consequently, the boot time of the corresponding systems in the vehicle (such as the in-vehicle infotainment system, autonomous driving system, etc.) will be significantly reduced.

[0008] Optionally, the step of adding file tags to multiple files contained in the root image file to obtain third system files includes: Obtain the target tag file, which includes file tags corresponding to each of the plurality of files; Based on the target tag file, file tags are written for multiple files contained in the root image file to obtain the third system file.

[0009] In the above method, by obtaining the target tag file, file tags are directly written to multiple files contained in the root image file based on the file tags set in the target tag file, which enables fast acquisition of file tags and thus improves the writing speed of subsequent file tags.

[0010] Optionally, the step of writing file tags for multiple files contained in the root image file based on the target tag file to obtain the third system file includes: For any one of the multiple files contained in the root image file, obtain the file tag corresponding to the file from the target tag file; The file tag corresponding to the file is saved as an extended attribute of the file, so that the file tag is written to the file, and the multiple files with the file tag written to them constitute the third system file.

[0011] Optionally, the target tag file includes multiple tag correspondences, which represent the correspondence between files and file tags in different paths. The step of writing file tags for multiple files contained in the root image file based on the target tag file to obtain the third system file includes: During the process of sequentially obtaining the tag correspondence from the target tag file, if a tag correspondence indicates that all files under the target path correspond to the target file tag, then for any one of the multiple files under the target path, the target file tag is saved as the file's extended attribute.

[0012] Optionally, the first system file further includes first program code, which is the program code corresponding to the boot process of the vehicle-mounted Linux system. Before compiling the first system file to obtain the second system file, the process further includes: Comment out the program code corresponding to the file tag writing operation in the first program code to update the first system file; Furthermore, after compiling the first system file to obtain the second system file, the process further includes: The reference file is located in the second system file and then deleted to obtain the updated second system file. The reference file is used to determine whether a file tag writing operation is performed during the boot process of the vehicle Linux system.

[0013] In the above method, the code corresponding to the file label writing operation in the first program code is removed by commenting out. This allows the program code corresponding to the file label writing operation to be restored during subsequent updates of the in-vehicle Linux system if file labels change and cause mismatches between files. This ensures that the file label writing operation is re-executed during system startup, guaranteeing the matching of files and their labels, and thus ensuring normal system operation. Furthermore, by deleting the reference file, it is not detected during system startup, thus assuming that all files in the system have already been labeled, and therefore no further file label writing operations will be performed.

[0014] Optionally, the first system file also includes the source code of a security policy file, which includes program code corresponding to multiple application scenarios. Before compiling the first system file to obtain the second system file, the process further includes: In response to the configuration operation of the target parameter, a second program code is determined from the source code of the security policy file. The second program code is the program code that is unrelated to the vehicle application scenario among the program codes corresponding to the multiple application scenarios. The target parameter is used to indicate the program code that does not participate in the compilation. And, the process of compiling the first system file to obtain the second system file includes: The remaining program code in the first system file, excluding the second program code, is compiled to obtain the second system file.

[0015] In the above method, by determining the second program code from the source code of the security policy file and specifying that the program code that is not related to the vehicle application scenario in the program code corresponding to multiple application scenarios will not be included in the subsequent compilation, the file size of the compiled security policy file can be reduced, thereby reducing the loading time of the security policy file during system startup.

[0016] Optionally, after creating the programming file for the vehicle-mounted chip based on the third system file, the process includes: The burning file is burned into the vehicle chip so that after the vehicle powers on the vehicle chip, the vehicle chip will no longer perform file tag writing operations during the first run of the vehicle Linux system.

[0017] In the above method, since file tags have already been written to each file in the root directory during the file creation process, each file already has a corresponding file tag. Therefore, it is unnecessary to perform the file tag writing operation again during the subsequent boot process. In this way, the time for writing file tags to each file during system boot can be saved, and the system restart time after the file tag writing operation is completed can also be saved, thus significantly reducing the initial boot time of the vehicle Linux system.

[0018] Secondly, a device for creating files for burning is provided, the device comprising: The compilation module is used to compile the first system file to obtain the second system file. The first system file refers to the source code file of the vehicle Linux system. The second system file includes a root image file, which is an image file of the root directory of the vehicle Linux system. The root directory contains files that need to be labeled during the startup process of the vehicle Linux system. The tag writing module is used to mount the root image file and write file tags for multiple files contained in the root image file to obtain third system files; The creation module is used to create a programming file for the vehicle-mounted chip based on the third system file.

[0019] Optionally, the tag writing module is specifically used for: Obtain the target tag file, which includes file tags corresponding to each of the plurality of files; Based on the target tag file, file tags are written for multiple files contained in the root image file to obtain the third system file.

[0020] Optionally, the tag writing module is specifically used for: For any one of the multiple files contained in the root image file, obtain the file tag corresponding to the file from the target tag file; The file tag corresponding to the file is saved as an extended attribute of the file, so that the file tag is written to the file, and the multiple files with the file tag written to them constitute the third system file.

[0021] Optionally, the target tag file includes multiple tag correspondences, which represent the correspondence between files and file tags at different paths. The tag writing module is specifically used for: During the process of sequentially obtaining the tag correspondence from the target tag file, if a tag correspondence indicates that all files under the target path correspond to the target file tag, then for any one of the multiple files under the target path, the target file tag is saved as the file's extended attribute.

[0022] Optionally, the first system file further includes first program code, which is program code corresponding to the boot process of the vehicle-mounted Linux system, and the device further includes: The comment module is used to comment out the program code corresponding to the file tag writing operation in the first program code, so as to update the first system file; The deletion module is used to find a reference file in the second system file and delete the reference file to obtain an updated second system file. The reference file is a file used to determine whether a file tag writing operation is performed during the boot process of the vehicle Linux system.

[0023] Optionally, the first system file further includes the source code of a security policy file, the source code of which includes program code corresponding to multiple application scenarios, and the device further includes: The parameter configuration module is used to determine the second program code from the source code of the security policy file in response to the configuration operation of the target parameter. The second program code is the program code that is unrelated to the vehicle application scenario among the program codes corresponding to the multiple application scenarios. The target parameter is used to indicate the program code that does not participate in the compilation. Furthermore, the compilation module is specifically used for: The remaining program code in the first system file, excluding the second program code, is compiled to obtain the second system file.

[0024] Optionally, the device further includes: The programming module is used to program the programming file into the vehicle chip, so that after the vehicle powers on the vehicle chip, the vehicle chip will no longer perform file tag writing operations during the first run of the vehicle Linux system.

[0025] Thirdly, a computer device is provided, the computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the above-described method for creating a burning file.

[0026] Fourthly, a vehicle, characterized in that the vehicle includes an on-board chip, the programming file of which is prepared based on the above-described programming file preparation method.

[0027] Fifthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described method for creating a burn-in file.

[0028] Sixthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the steps of the above-described method for creating a burning file.

[0029] It is understood that the beneficial effects of the second, third, fourth, fifth, and sixth aspects mentioned above can be found in the relevant descriptions in the first aspect above, and will not be repeated here. Attached Figure Description

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

[0031] Figure 1 This is a flowchart illustrating the creation of a file burning process in the prior art, as provided in an embodiment of this application. Figure 2 This is a flowchart illustrating the initial boot of an in-vehicle Linux system according to an embodiment of this application; Figure 3 This is an initialization flowchart of a security policy file provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a method for creating a burning file according to an embodiment of this application; Figure 5 This is a flowchart of another method for creating a burning file provided in an embodiment of this application; Figure 6 This is another flowchart of the first boot of an in-vehicle Linux system provided in this application embodiment; Figure 7 This is a schematic diagram of a file burning device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0033] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0034] First, the terms used in the embodiments of this application will be explained.

[0035] 1. SELinux SELinux is a mandatory access control security module embedded in the Linux kernel. Its core goal is to restrict process permissions, ensuring that each process only receives the minimum permissions necessary to complete its task, preventing the abuse of additional permissions. Process and file permissions are uniformly managed by system-preset policies and are not affected by user or process-specific modifications.

[0036] SELinux primarily includes three operating modes: Enforcing mode, Permissive mode, and Disabled mode. Enforcing mode is the system default mode; it enforces access according to the security policy. If the access rules violate the security policy, the access request is rejected and logged. In Permissive mode, access is enforced according to the security policy, but if an access request violates the security policy, the request is not rejected; it is simply logged. Disabled mode means SELinux is turned off, and access is not enforced according to the security policy.

[0037] Under normal circumstances, when SELinux is in Enforcing or Permissive mode, the Linux system will perform access control according to the SELinux security policy.

[0038] Furthermore, SELinux's security policy primarily defines access permissions between subjects and objects, such as which subjects can access which objects. The kernel then verifies the legitimacy of access requests based on this security policy. Here, the subject refers to the object initiating the access request; in Linux systems, subjects are primarily system processes. The object refers to the resource being accessed, including files, directories, network ports, devices, etc.

[0039] 2. ext4 (Fourth Extended Filesystem) ext4 is a commonly used journaling file system in Linux systems and is the default file system for most Linux systems.

[0040] Generally, compiling the source code of a Linux system yields an ext4 file, which can be considered an ext4 image file of the root directory. This ext4 file is typically a single binary file containing the complete root directory structure (all directories and files such as / bin, / etc, / lib), packaged in the ext4 filesystem format. Subsequently, this ext4 file is burned to the root partition of the storage medium. After the kernel boots and mounts the root partition, it can recognize all files within that partition, thus enabling access to all files on that partition.

[0041] Before describing the method for creating the burning file provided in the embodiments of this application, the application scenarios of the embodiments of this application will be explained first.

[0042] The following is combined Figure 1 and Figure 2 This paper describes the process from creating the burning file to booting the in-vehicle Linux system in the existing technology.

[0043] For example, Figure 1 This is a flowchart illustrating the creation process of burning files in the prior art, as provided in an embodiment of this application.

[0044] Currently, automotive-grade chips in vehicle hardware often employ a multi-core heterogeneous architecture, where different operating systems can run on multiple cores. For example, one core might run Linux, while another runs a microcontroller. By assigning specific tasks to different cores, the system avoids global risks caused by a single core failure, thus improving safety. Furthermore, allowing different cores to handle different tasks reduces unnecessary power consumption and improves operational efficiency.

[0045] For example, such as Figure 1 As shown, an automotive chip includes an A-core and an M-core. The A-core runs a Linux system, and the M-core runs a microcontroller system. Figure 1The diagram shows the process of creating the programming file corresponding to this automotive chip.

[0046] See Figure 1 For the A kernel, the source code of the in-vehicle Linux system within the A kernel is first compiled to obtain the A kernel compiled file, which can also be considered as the image file of the in-vehicle Linux system. One possible approach is to use the Yocto compilation tool to compile the A kernel source code. The resulting A kernel compiled file can include an ext4 file (the image file in the root directory), an image file (the kernel image), and a dtb file (the device tree binary file).

[0047] For the M-core, the source code of the microcontroller system (M-core source code) can be compiled to obtain the M-core compiled file, which is also the system image of the microcontroller system. Finally, the A-core compiled file and the M-core compiled file are packaged together to obtain the programming file. Subsequently, this programming file can be programmed to different partitions of the automotive chip at the same time (the A-core image corresponds to the main core storage area, and the M-core image corresponds to the real-time core dedicated storage area), thus enabling the running of different operating systems on the automotive chip.

[0048] After the programming file is burned into the automotive chip, power is supplied to the chip. Upon power-up, the chip's built-in boot program is triggered. This program loads the M-core image file into the M-core's memory, and the M-core immediately begins running its tasks. Additionally, the boot program loads the A-core image file into the A-core's memory, starting with the Linux kernel. After the Linux kernel boots, other processes can be started, thus booting the automotive Linux system and enabling it to run on the automotive chip.

[0049] With the addition of SELinux to an in-vehicle Linux system, access requests from processes within the Linux system must adhere to the access rules defined in the security policy. In SELinux, each subject and object has a corresponding file label, and the access rules defined in the security policy set access permissions based on these file labels. For example, an access rule defined in the security policy might be: `allow user_t passwd_exec_t : file {read getattr execute open}`. This rule instructs a process with the label `user_t` to have read and execute permissions on a file labeled `passwd_exec_t`.

[0050] Without SELinux, files in a Linux system lack corresponding file tags. However, by adding SELinux to the in-vehicle Linux system, file tags can be written during the initial boot after the system is flashed, giving files the appropriate tags. This allows the in-vehicle Linux system to subsequently perform access control according to the access rules defined in the security policy.

[0051] For example, Figure 2 This is a flowchart of the first boot of an in-vehicle Linux system provided in an embodiment of this application.

[0052] like Figure 2 As shown, after the Linux kernel boots, the kernel determines the SELinux operating mode. When SELinux is in Disabled mode, it means SELinux is disabled, and subsequent access control according to security policies is unnecessary. In this case, the init process can directly perform system initialization. When SELinux is in Enforcing or Permissive mode, it means that access control according to security policies is required within the system. Therefore, the security policy file can be loaded, and system initialization can then proceed.

[0053] During the actual loading of the security policy file, the kernel first starts the first application-layer process (init process). Then, the init process is responsible for the SELinux initialization process, which involves initializing the security policy file (Policy.X) to load the "access rules" into memory. The specific loading process is as follows: Figure 3 As shown. After initializing the security policy file, the label of the init process can be obtained and reset. The init process can then read the configuration file to start subsequent child processes according to the child process startup order configured in the configuration file, thereby completing the system initialization operation.

[0054] For example, Figure 3 This is an initialization flowchart of a security policy file provided in an embodiment of this application.

[0055] like Figure 3As shown, when initializing the security policy file, the / proc directory is mounted first. Before loading the security policy file (Policy.X), it's necessary to confirm whether SELinux is enabled in the kernel, and this configuration information needs to be obtained through / proc. For example, the init process reads relevant files in / proc to determine whether SELinux is loaded and whether there are disabling boot parameters such as selinux=0. If / proc is not mounted, the init process cannot obtain these critical states, and directly mounting / sys / fs / selinux may result in compatibility errors.

[0056] In this scenario, after mounting the / proc directory, the / sys / fs / selinux directory is mounted. Since / sys / fs / selinux / load is the kernel's policy loading interface, mounting the / sys / fs / selinux directory allows the init process to access this directory. This enables the security policy file (Policy.X) to be loaded into / sys / fs / selinux / load, allowing the loaded security policy to be enabled later.

[0057] However, since the files in the system do not yet have corresponding file tags, after the init process completes system initialization, it first runs `selinux-autorelabel.sh`. After running `selinux-autorelabel.sh`, it checks if a `.autorelabel` file exists in the root directory. If a `.autorelabel` file exists in the root directory, it means that the file tag writing operation has not yet been performed on all files in the entire file system; that is, the files in the system have not yet been labeled with their corresponding file tags. If a `.autorelabel` file does not exist in the root directory, it means that the file tag writing operation has been performed on all files in the entire file system; that is, the files in the system have been labeled with their corresponding file tags. In this case, the init process can continue to execute subsequent child processes.

[0058] If an .autorelabel file is detected in the root directory, fixfiles can be used to write file labels to all files in the file system. After writing file labels to every file in the file system, the .autorelabel file in the root directory is deleted, and finally, the reboot program is executed to restart the system.

[0059] However, during the initial boot of the aforementioned in-vehicle Linux system, it's necessary to determine whether files in the file system have been tagged. If files haven't been tagged, tags must be written to each file in the root directory. Since writing tags requires traversing the entire file system and performing a write operation on each file, this process is very time-consuming, impacting the boot speed of the in-vehicle Linux system and significantly slowing it down. Furthermore, after writing tags to each file in the file system, the `.autorelabel` file in the root directory must be deleted, and the `reboot` program must be executed to restart the system. Rebooting the system also incurs some boot time, further slowing down the boot process of the in-vehicle Linux system.

[0060] Therefore, this application provides a method for creating a burning file, which can be applied to the above-mentioned... Figure 1 The process of creating the burned files is described.

[0061] This method of creating the burning file allows for the writing of corresponding file tags to files that need to be tagged during the burning process. This eliminates the need to write file tags to files in the file system during the first boot of the vehicle Linux system after the burning file is burned to the vehicle chip. This saves time spent writing file tags during system boot and also saves time spent restarting the system, thus significantly reducing the first boot time of the vehicle Linux system.

[0062] The method for creating the burning file provided in the embodiments of this application will be explained in detail below.

[0063] Figure 4 This is a flowchart illustrating a method for creating a burning file according to an embodiment of this application. This method can be applied to computer devices. See also... Figure 4 The method includes the following steps 401-403.

[0064] Step 401: Compile the first system file to obtain the second system file. The first system file refers to the source code file of the vehicle Linux system. The second system file includes the root image file, which is the image file of the root directory of the vehicle Linux system. The root directory contains files that need to be written with file tags during the startup process of the vehicle Linux system.

[0065] It should be understood that the second system file is the compiled file obtained after compiling the source code files of the in-vehicle Linux system; that is, the compiled file corresponding to the in-vehicle Linux system. Generally, the second system file can include an ext4 file, an image file, and a dtb file. The ext4 file is a root directory system image in ext4 format, a disk image file containing the complete user space within the system. The image file is the output of compiling the system kernel source code; it is an image of the in-vehicle Linux system kernel and contains the core logic of the in-vehicle Linux system. The dtb file is a file used to describe the topology of the device hardware; after booting, it is loaded into memory and can inform the kernel of the current hardware configuration information.

[0066] In this embodiment of the application, the root image file is also the ext4 file.

[0067] One possible approach is to use the yocto compiler to compile the first system file to obtain the second system file.

[0068] Since existing technology performs file tag writing operations on all files in the root directory during the initial system startup, if file tags need to be written to files in advance during the creation of the burning file, the image file in the root directory can be manipulated. After the burning file is created based on this and burned to the automotive chip, the files in the root directory will all have file tags written on them after the system starts up.

[0069] In this embodiment of the application, the source code of the security policy file in the first system file can be trimmed before compiling the first system file.

[0070] The first system file includes the source code for the security policy file.

[0071] Because the security policy file needs to be loaded into the kernel's policy loading interface during system startup, the file size of the security policy file directly affects the file loading time, which in turn affects the system startup time.

[0072] In the above method, by trimming the source code of the security policy file, the amount of content to be compiled is reduced, thereby decreasing the file size of the compiled security policy file. This, in turn, reduces the loading time of the security policy file during system startup, and further reduces the initial boot time of the in-vehicle Linux system. For example, if the original security policy file was approximately 3MB, the compiled file size would be approximately 600KB, reducing the loading speed from 620ms to 320ms.

[0073] One possible approach to trimming the source code of the security policy file in the first system file is to determine the second program code from the source code of the security policy file in response to the configuration operation of the target parameters.

[0074] The target parameter indicates which program code should not be included in the compilation. The Yocto compiler has a feature to specify modules that should not be compiled; this can be achieved by setting the target parameter. For example, the target parameter could be `PURGE_POLICY_MODULES`.

[0075] The second set of program code consists of program code that is unrelated to the in-vehicle application scenario from among the program code corresponding to multiple application scenarios. It should be understood that the source code of the security policy file includes program code corresponding to multiple application scenarios, where multiple application scenarios are a complete set applicable to all usage scenarios, including those related to in-vehicle application scenarios and those unrelated to in-vehicle application scenarios.

[0076] In this scenario, compiling the entire source code of the security policy file would yield a complete compiled file covering all scenarios. However, this embodiment applies to an automotive chip, so in actual use, only the automotive application scenario-related parts of the security policy file are involved. Therefore, setting the compilation process to not compile the second program code will not affect actual use.

[0077] In the above method, by determining the second program code from the source code of the security policy file and specifying that the program code that is not related to the vehicle application scenario in the program code corresponding to multiple application scenarios will not be included in the subsequent compilation, the file size of the compiled security policy file can be reduced, thereby reducing the loading time of the security policy file during system startup.

[0078] In this case, step 401 can be performed by compiling the remaining program code in the first system file, excluding the second program code, to obtain the second system file.

[0079] In this way, by compiling only the program code related to the application scenarios of the in-vehicle Linux system, the size of the compiled security policy file can be reduced, and the size of the second system file can be reduced, which can reduce the boot time of the in-vehicle Linux system.

[0080] The source code of the vehicle-mounted Linux system can be compiled through the above step 401 to obtain the compiled second system file. In this embodiment of the application, file tags can be written for the files in the root directory in advance during the creation of the burning file. In this case, the following step 402 can be executed.

[0081] Step 402: Mount the root image file and write file tags for the multiple files contained in the root image file to obtain the third system files.

[0082] It should be understood that the multiple files contained in the root image file correspond to the multiple files in the root directory. Therefore, writing file tags for the multiple files contained in the root image file is equivalent to writing file tags for the multiple files in the root directory.

[0083] Since the burning process is not in the actual Linux system operating environment, to enable writing file tags to multiple files, the root image file can be mounted. This simulates the Linux system's file tag writing environment, allowing access to each file in the root directory and thus enabling the successful writing of file tags to the files in the root directory.

[0084] In the above method, by writing file tags to multiple files in the root directory during the creation of the burning file, the vehicle Linux system does not need to write file tags to the files in the file system during the first boot process after the burning file is burned to the vehicle chip. This saves time in writing file tags during the system boot process, thus significantly reducing the first boot time of the vehicle Linux system.

[0085] One possible approach is to write file tags to multiple files contained in the root image file to obtain the third system files. This can be done by: obtaining the target tag file; and based on the target tag file, writing file tags to multiple files contained in the root image file to obtain the third system files.

[0086] The target tag file includes file tags corresponding to each file in multiple files. In this embodiment, the core content of the target tag file is to establish the correspondence between file system paths and file tags, so as to clarify the file tags corresponding to different files.

[0087] In the above method, by obtaining the target tag file, file tags are directly written to multiple files contained in the root image file based on the file tags set in the target tag file, which enables fast acquisition of file tags and thus improves the writing speed of subsequent file tags.

[0088] In this embodiment, the file tags set for each file in the target tag file can be set in two ways: First, on a file-by-file basis, meaning each file has its own corresponding file tag. Second, on a class-by-class basis, the target tag file can include multiple tag mappings. These mappings represent the correspondence between files and file tags under different paths. That is, files under a certain path are considered a class of files, and these files share the same file tag; therefore, this file tag can be written to all files in this class. Furthermore, each tag mapping in the target tag file can use the format "path regular expression + file tag" to explicitly specify which security tag should match a file or directory under a specific path.

[0089] In this case, the operation of writing file tags for multiple files contained in the root image file based on the target tag file to obtain the third system file can be implemented through the following two possible implementation methods.

[0090] In the first possible implementation, for any one of the multiple files contained in the root image file, the file tag corresponding to this file is obtained from the target tag file; the file tag corresponding to this file is saved as an extended attribute of this file, so that a file tag is written for this file, and the multiple files with written file tags constitute a third system file.

[0091] The above method involves starting from the file, searching for file tags in the target tag file, and writing the file tags. Essentially, for each file under the root image file, the corresponding file tag is obtained from the target tag file, and then the obtained file tag is written to the extended attributes of the file through a write operation, thereby achieving the goal of writing file tags for the file.

[0092] It should be understood that performing the above operation on each of the multiple files contained in the root image file can write a file tag to each file. In this case, after all files in the root image file under the second system file have their file tags written, the third system file is formed. That is, the third system file is the second system file with its file tags written on it.

[0093] In the second possible implementation, during the process of obtaining the tag correspondence from the target tag file in sequence, if a tag correspondence is obtained indicating that all files under the target path correspond to the target file tag, then for any one of the multiple files under the target path, the target file tag is saved as the extended attribute of that file.

[0094] When the target tag file contains multiple tag correspondences, the tag correspondences can be obtained sequentially from the target tag file, and the target file and its corresponding file tag can be determined based on the obtained tag correspondences. Then, the file tag corresponding to the target file is saved as an extended attribute of the target file so that the target file is written with the corresponding tag file.

[0095] The target file is the file whose file tag is about to be written.

[0096] The above method starts from the target tag file, first determines the file to be tagged and the file tag, and then performs the write operation. That is, after obtaining a tag correspondence, the file to be tagged and the file tag corresponding to that file can be obtained from the correspondence between the file and the file tag under the path indicated by the tag correspondence. Then, the corresponding file tag can be written to the file in the way of extended attributes through the write operation.

[0097] It should be understood that the path in the tag mapping is the path where the file is located. In some cases, a path may include one file or multiple files. When a path includes multiple files, the file tags corresponding to these multiple files may be the same. In this case, the target tag file uses a tag mapping to reflect the correspondence between the files under this path and the file tags.

[0098] If a tag mapping relationship is obtained indicating that all files under the target path correspond to a file tag, then the file tag can be written for each file under the target path. Therefore, for each file in multiple files under the target path, the target file tag can be saved as an extended attribute of each file, so that each file can be written with the target file tag.

[0099] The above explains the operation of writing file tags to the files contained in the root image file. It should be understood that after writing file tags to each file in advance during the creation of the burning file, there is no need to perform the file tag writing operation again during the subsequent system startup process. In this case, it is also necessary to remove the program code related to the file tag writing operation before compiling the first system file.

[0100] One possible approach is to comment out the program code corresponding to the file tag writing operation in the first program code before compiling the first system file to obtain the second system file, so as to update the first system file.

[0101] The first program code corresponds to the boot process of the in-vehicle Linux system. In this embodiment, during the boot process of the in-vehicle Linux system, an init process is started first, and then the init process performs the file label writing operation. In this case, the program code corresponding to the file label writing operation of the init process in the first program code can be commented out, so that the init process no longer performs the file label writing operation during system boot. For example, the program code corresponding to the init process starting selinux-autorelabel.sh, checking whether the .autorelabel file exists in the root directory, and performing the file label writing operation on all files when the .autorelabel file exists can be commented out.

[0102] In the above method, the program code corresponding to the file label writing operation in the first program code is removed by commenting. This allows the program code corresponding to the file label writing operation to be restored if the file labels change during subsequent updates of the vehicle Linux system, resulting in mismatches between the file labels of various files. This enables the file label writing operation to be re-executed during system startup, thereby ensuring the matching of each file with its file label and ensuring the normal operation of the system.

[0103] In this case, the updated first system file can be compiled to obtain the second system file. It's worth noting that after obtaining the second system file, reference files can be located within it and deleted to obtain the updated second system file.

[0104] The reference file is used to determine whether a file label writing operation is performed during the boot process of the in-vehicle Linux system; the reference file is the .autorelabel file.

[0105] Since an `.autorelabel` file is generated by default after compiling the first system file, the above method deletes the reference file so that it is not detected during system startup. This assumes that all files in the system have already been tagged, and therefore no further file tag writing operations will be performed.

[0106] Steps 401-402 above compile the first system file and write file tags to each file under the root image file in the compiled second system file. This is equivalent to performing the file tag writing operation during the compilation stage, allowing each file to be tagged. After compilation is complete, a burning file can be created based on the compiled file, that is, continue to execute step 403 below.

[0107] Step 403: Based on the third system file, create the programming file for the vehicle chip.

[0108] One possible approach is to package the third-party system files to obtain the programming files for the vehicle-mounted chip.

[0109] It should be understood that the third system file is the compilation file corresponding to the vehicle-mounted Linux system. When the vehicle-mounted chip has a single-core or multi-core homogeneous structure, the vehicle-mounted chip can only run the vehicle-mounted Linux system. Therefore, the third system file can be directly packaged. The packaged file is the burning file of the vehicle-mounted Linux system, which is also the burning file of the vehicle-mounted chip.

[0110] In the case of a multi-core heterogeneous structure for automotive chips, which means that multiple different operating systems can run, a fourth system file can be obtained. Then, based on the third and fourth system files, the programming file for the automotive chip can be created.

[0111] The fourth system file is the compilation file for other operating systems besides the in-vehicle Linux system. For example, if the A core of an in-vehicle chip can run the in-vehicle Linux system, and the M core of the in-vehicle chip can run a microcontroller system, then the fourth system file is the compilation file for the M core, which is the compilation file for the microcontroller system.

[0112] In this case, based on the third system file and the fourth system file, the operation to create the programming file for the vehicle chip can be: package the third system file and the fourth system file together to obtain the programming file for the vehicle chip.

[0113] Furthermore, after creating the programming file for the vehicle chip, the programming file can be programmed into the vehicle chip so that when the vehicle powers on the vehicle chip, the vehicle chip will no longer perform file tag writing operations during the first run of the vehicle Linux system.

[0114] After the flashing file is burned into the automotive chip, a running automotive Linux system is deployed in the chip. During vehicle startup, the vehicle can power on the chip, allowing it to execute the corresponding boot program to run the automotive Linux system.

[0115] Since file tags were already written to each file in the root directory during the burning process, each file already has its own tag. Therefore, it's unnecessary to perform the file tag writing operation again during the subsequent boot process. This saves time spent writing file tags during system boot and also reduces the system restart time after the file tag writing operation, significantly reducing the initial boot time of the in-vehicle Linux system. Consequently, the boot time of corresponding systems in the vehicle (such as in-vehicle infotainment systems, autonomous driving systems, etc.) is also faster.

[0116] To facilitate understanding, we will now combine... Figure 5 and Figure 6 The process of creating the burning file and booting the vehicle-mounted Linux system involved in the embodiments of this application is described.

[0117] For example, Figure 5 This is a flowchart of another method for creating a burning file provided in an embodiment of this application.

[0118] See Figure 5 For the A-core, the source code of the vehicle Linux system in the A-core (A-core source code) is first compiled to obtain the A-core compiled file (i.e., the second system file). The second system file may include the ext4 file (root image file), the image file, and the dtb file.

[0119] Then, the ext4 file can be mounted, and file tags can be written to each file contained in the ext4 file. This allows each file to be pre-labeled. The ext4 file, image file, and dtb file with the file tags can then form a third system file. This is equivalent to obtaining the compiled file corresponding to the in-vehicle Linux system with the file tags pre-labeled.

[0120] For the M-core, the microcontroller system source code can be compiled to obtain the M-core compiled file, which is also the system image of the microcontroller system. Finally, the third-party system files and the M-core compiled file are packaged together to obtain the programming file. Subsequently, this programming file can be programmed to different partitions of the automotive chip at the same time (the A-core image corresponds to the main core storage area, and the M-core image corresponds to the real-time core dedicated storage area), thus enabling the running of different operating systems on the automotive chip.

[0121] After the flashing file is burned into the automotive chip, a runnable automotive Linux system is deployed within the chip. This system can then run when the chip is powered on. The following section describes the process of booting the automotive Linux system in a vehicle, using the vehicle as the primary example.

[0122] For example, Figure 6 This is a flowchart of the first boot of another in-vehicle Linux system provided in this application embodiment.

[0123] like Figure 6 As shown, firstly, the vehicle powers on the onboard chip. After the chip is powered on, the programmable file burned into it begins to run. This file includes a boot program, which the chip can then run. During the initialization phase, the Linux kernel can be started first. After the Linux kernel starts, it determines the SELinux operating mode. When SELinux is in Disabled mode, the init process directly performs system initialization. When SELinux is in Enforcing or Permissive mode, it indicates that access control according to a security policy is required. Therefore, the security policy file can be initialized, followed by system initialization. The specific process for initializing the security policy file is as follows... Figure 1 The initialization process of the security policy file described in the embodiments is the same, and will not be repeated here.

[0124] It should be noted that in this embodiment, the file tag writing operation during the file creation stage only involves files in the system root directory. The init process, being the main body of the system, is not a file and therefore not an object for pre-writing file tags. In this case, after the security policy file initialization is completed, the init process's tag can still be obtained, and the tag can be reset for the init process. Afterward, the init process can perform system initialization operations.

[0125] Specifically, the init process can read the configuration file and start subsequent child processes according to the child process startup order configured in the configuration file, thereby completing the system initialization operation.

[0126] However, since file labels were pre-written for the files in the root directory during the creation of the burning files, and the program code corresponding to the file label writing operation was commented out, during the first boot of the vehicle's onboard Linux system, after the init process completes the system initialization operation, there is no need to run selinux-autorelabel.sh. Instead, the subsequent child processes will continue to be executed directly to enter the normal operation of the system.

[0127] Thus, during the initial startup of the in-vehicle Linux system, there is no need to write file tags to the files in the file system through file tag writing operations. This saves time spent writing file tags during system startup and also saves time spent restarting the system. Consequently, the initial startup time of the in-vehicle Linux system is significantly reduced, and the startup time of corresponding systems in the vehicle (such as in-vehicle infotainment systems, autonomous driving systems, etc.) is significantly faster.

[0128] In this embodiment, the computer device first compiles the source code files of the in-vehicle Linux system to obtain a second system file. This second system file includes a root image file, which is an image of the root directory of the in-vehicle Linux system. Typically, during the boot process of the in-vehicle Linux system, file tags are written to the files in the root directory. Since the root image file has the same directory structure and format as the root directory, file tags can be written to the files under the root image file during the creation process. Next, the root image file is mounted, making all files under it accessible. Then, file tags are written to the multiple files contained in the root image file to obtain a third system file—that is, a system file with the file tags already written. Finally, the programming file for the in-vehicle chip is created based on the third system file. In this way, after the prepared burning file is burned to the vehicle chip, during the first boot of the vehicle Linux system, there is no need to write file tags to the files in the root directory through write operations. This saves the time spent writing file tags to each file during the system boot process, thus significantly reducing the first boot time of the vehicle Linux system. Consequently, the boot time of the corresponding systems in the vehicle (such as the in-vehicle infotainment system, autonomous driving system, etc.) is significantly faster.

[0129] Figure 7 This is a schematic diagram of a file burning device provided in an embodiment of this application. The file burning device can be implemented as part or all of a computer device by software, hardware, or a combination of both. This computer device can be as described below. Figure 8 The computer equipment shown. See also Figure 7 The device includes: a compilation module 701, a tag writing module 702, and a production module 703.

[0130] The compilation module 701 is used to compile the first system file to obtain the second system file. The first system file refers to the source code file of the vehicle Linux system. The second system file includes the root image file, which is the image file of the root directory of the vehicle Linux system. The root directory contains files that need to be written with file tags during the startup process of the vehicle Linux system. The tag writing module 702 is used to mount the root image file and write file tags for multiple files contained in the root image file to obtain the third system files; Module 703 is used to create programming files for automotive chips based on third-party system files.

[0131] Optionally, the tag writing module 702 is specifically used for: Obtain the target tag file, which includes the file tags corresponding to each of the multiple files; Based on the target tag file, file tags are written for multiple files contained in the root image file to obtain the third system file.

[0132] Optionally, the tag writing module 702 is specifically used for: For any one of the multiple files contained in the root image file, obtain the file tag corresponding to the file from the target tag file; The file tag corresponding to the file is saved as an extended attribute of the file, so that file tags are written to the file, and multiple files with written file tags constitute a third system file.

[0133] Optionally, the target tag file includes multiple tag mappings, which are used to represent the correspondence between files and file tags at different paths. The tag writing module 702 is specifically used for: During the process of sequentially retrieving tag correspondences from the target tag file, if a tag correspondence indicates that all files under the target path correspond to the target file tag, then for any one of the multiple files under the target path, the target file tag is saved as an extended attribute of the file.

[0134] Optionally, the first system file also includes first program code, which is the program code corresponding to the boot process of the vehicle-mounted Linux system. The device also includes: The comment module is used to comment out the program code corresponding to the file label writing operation in the first program code, so as to update the first system files; The deletion module is used to find the reference file from the second system files and delete the reference file to obtain the updated second system files. The reference file is used to determine whether a file tag writing operation is performed during the boot process of the vehicle Linux system.

[0135] Optionally, the first system file also includes the source code of a security policy file, which includes program code corresponding to multiple application scenarios. The device also includes: The parameter configuration module is used to determine the second program code from the source code of the security policy file in response to the configuration operation of the target parameter. The second program code is the program code that is unrelated to the vehicle application scenario among the program codes corresponding to multiple application scenarios. The target parameter is used to indicate the program code that does not participate in the compilation. Furthermore, compiler module 701 is specifically used for: The remaining program code in the first system file, excluding the second program code, is compiled to obtain the second system file.

[0136] Optionally, the device further includes: The programming module is used to program the files into the vehicle chip, so that when the vehicle powers on the chip, the chip will not perform file tag writing operations during the first run of the vehicle Linux system.

[0137] In this embodiment, the source code files of the in-vehicle Linux system are first compiled to obtain a second system file. This second system file includes a root image file, which is an image of the root directory of the in-vehicle Linux system. During the boot process of the in-vehicle Linux system, file tags are typically written to the files in the root directory. Since the root image file has the same directory structure and format as the root directory, file tags can be written to the files under the root image file during the creation process. Next, the root image file is mounted, making all files under it accessible. Then, file tags are written to the multiple files contained in the root image file to obtain a third system file—that is, a system file with the file tags already written. Finally, the programming file for the in-vehicle chip is created based on the third system file. In this way, after the prepared burning file is burned to the vehicle chip, the vehicle Linux system will not need to write file tags to the files in the root directory during the first boot process. This saves time in writing file tags to each file during the system boot process, thus significantly reducing the first boot time of the vehicle Linux system. Consequently, the boot time of the corresponding systems in the vehicle (such as the in-vehicle infotainment system, autonomous driving system, etc.) will be significantly faster.

[0138] It should be noted that the above-described device for creating programming files for automotive chips is only illustrated by the division of the above-described functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0139] The functional units and modules in the above embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of the embodiments of this application.

[0140] The apparatus and method for creating files provided in the above embodiments belong to the same concept. The specific working process and technical effects of the units and modules in the above embodiments can be found in the method embodiments section, and will not be repeated here.

[0141] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 8 As shown, the computer device 800 includes: a processor 80, a memory 81, and a computer program 82 stored in the memory 81 and executable on the processor 80. When the processor 80 executes the computer program 82, it implements the steps in the file burning method described in the above embodiments.

[0142] The computer device 800 can be a general-purpose computer device. In specific implementations, the computer device 800 can be a desktop computer, a portable computer, a handheld computer, a mobile phone, a tablet computer, or other terminal devices. This application embodiment does not limit the type of computer device 800. Those skilled in the art will understand that... Figure 8 This is merely an example of computer device 800 and does not constitute a limitation on computer device 800. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0143] Processor 80 can be a Central Processing Unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0144] In some embodiments, memory 81 may be an internal storage unit of computer device 800, such as a hard disk or memory of computer device 6. In other embodiments, memory 81 may be an external storage device of computer device 800, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on computer device 800. Furthermore, memory 81 may include both internal and external storage units of computer device 800. Memory 81 is used to store operating system, application programs, boot loader, data, and other programs. Memory 81 may also be used to temporarily store data that has been output or will be output.

[0145] This application also provides a vehicle, which includes an on-board chip. The on-board chip can be a controller in the vehicle, such as a domain controller or an on-board multimedia host. This application does not limit this specific application. The on-board chip can be pre-programmed with files, and these files can be created based on the file creation method described in the above embodiments.

[0146] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.

[0147] This application provides a computer program product that, when run on a computer, causes the computer to perform the steps described in the various method embodiments above.

[0148] If the integrated unit is implemented as 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, all or part of the processes in the above method embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate form. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a photographing device / terminal device, a recording medium, a computer memory, ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage devices. The computer-readable storage medium mentioned in this application can be a non-volatile storage medium; in other words, it can be a non-transient storage medium.

[0149] It should be understood that all or part of the steps of the above embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented in whole or in part as a computer program product. The computer program product includes one or more computer instructions. The computer instructions can be stored in the above-described computer-readable storage medium.

[0150] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0151] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented 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 this application.

[0152] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0153] The units described as separate components may or may not be physically separate. 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method of creating a burn file, characterized by, The method comprises: compiling a first system file to obtain a second system file, the first system file being a source code file of a vehicle-mounted Linux system, and the second system file comprising a root image file, the root image file being an image file of a root directory in the vehicle-mounted Linux system, and the root directory comprising files that need to be written with file tags in a startup process of the vehicle-mounted Linux system; mounting the root image file and writing file tags for a plurality of files contained in the root image file to obtain a third system file; based on the third system file, making a burning file for a vehicle-mounted chip.

2. The method of claim 1, wherein, The method comprises: obtaining a target tag file, the target tag file comprising file tags corresponding to each of the plurality of files; based on the target tag file, writing file tags for the plurality of files contained in the root image file to obtain the third system file.

3. The method of claim 2, wherein, The method comprises: for any one of the plurality of files contained in the root image file, obtaining a file tag corresponding to the file from the target tag file; saving the file tag corresponding to the file as an extended attribute of the file, so that the file is written with the file tag, and the plurality of files written with the file tags constitute the third system file.

4. The method of claim 2, wherein, The target tag file comprises a plurality of tag correspondence relationships, the plurality of tag correspondence relationships being used to represent a correspondence relationship between files of different paths and file tags, and the method comprises: in the process of sequentially obtaining tag correspondence relationships from the target tag file, if a tag correspondence relationship indicates that all files under a target path correspond to a target file tag, for any one of the plurality of files under the target path, the target file tag is saved as an extended attribute of the file.

5. The method of claim 1, wherein, The first system file further comprises first program code corresponding to a startup process of the vehicle-mounted Linux system, and before the compiling of the first system file to obtain the second system file, the method further comprises: annotating program code corresponding to a file tag writing operation in the first program code to update the first system file; and after the compiling of the first system file to obtain the second system file, the method further comprises: finding a reference file from the second system file and deleting the reference file to obtain an updated second system file, the reference file being a file used to determine whether a file tag writing operation is performed in the startup process of the vehicle-mounted Linux system.

6. The method according to any one of claims 1 to 5, wherein, The first system file further includes source code of a security policy file, the source code of the security policy file including program codes corresponding to multiple application scenarios, and before the compiling of the first system file to obtain the second system file, the method further includes: in response to a configuration operation on a target parameter, determining second program code from the source code of the security policy file, the second program code being program code irrelevant to the vehicle application scenario among the program codes corresponding to the multiple application scenarios, the target parameter being used to indicate program code not participating in the compiling; and the compiling of the first system file to obtain the second system file includes: compiling the remaining program code except the second program code in the first system file to obtain the second system file.

7. The method according to any one of claims 1 to 5, wherein After the third system file is used to make a burning file of the vehicle chip, the method further includes: burning the burning file into the vehicle chip, so that after the vehicle is powered on, the vehicle chip no longer performs the file tag writing operation in the process of first running the vehicle Linux system.

8. An apparatus for creating a file for burning, characterized by comprising: The device includes: compiling a first system file to obtain a second system file, the first system file being a source code file of a vehicle Linux system, the second system file including a root image file, the root image file being a mirror image file of a root directory in the vehicle Linux system, the root directory containing files needing to write file tags in the process of starting the vehicle Linux system; mounting the root image file and writing file tags for multiple files contained in the root image file to obtain a third system file; based on the third system file, making a burning file of a vehicle chip.

9. A computer device, comprising: The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is executed by the processor to implement the method in any one of claims 1 to 7.

10. A vehicle characterized by comprising: The vehicle includes a vehicle chip, and a burning file of the vehicle chip is made based on the method in any one of claims 1 to 7.

Images