File processing method and device in embedded system, equipment and storage medium

Abstract

The application provides a file processing device method and device in an embedded system, electronic equipment and a computer readable storage medium, comprising: obtaining an additional directory, a first target file and a first archive file; the directory structure of the additional directory is consistent with that of the first archive file; the first archive file is an archive file corresponding to a first root file system; the first root file system is a component connecting a kernel and an application program in the embedded system; the first target file is added under the additional directory; according to a preset script, the directory structure of the additional directory and the first target file are appended to the end of the first archive file to obtain a second archive file; and the first root file system is updated according to the second archive file to obtain a second root file system. The application embodiment can directly append the file to be added to the end of the first archive file, without full unpacking and repacking, thereby improving the development iteration speed and the debugging efficiency.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a file processing method, apparatus, electronic device, and computer-readable storage medium in an embedded system. Background Technology

[0002] In the field of chip-based embedded system development, Buildroot, as a widely used embedded Linux system building tool, can automatically generate complete system images, including the root file system. Among them, rootfs.cpio, a common root file system archive format, is widely used in scenarios such as initramfs due to its small size and fast boot speed.

[0003] In related technologies, when developers need to add or update user-defined files to an existing rootfs.cpio filesystem, they typically need to completely decompress the rootfs.cpio archive to a temporary directory, copy the files to be added or updated to the appropriate path in the temporary directory, and then repackage the entire directory structure within that temporary directory to generate a new rootfs.cpio file.

[0004] However, even when only adding or modifying a single file, the methods in these technologies require a complete "unpacking-modification-packaging" process. Unpacking and repackaging are time-consuming, which seriously affects the efficiency of development iteration and debugging. Summary of the Invention

[0005] This application provides a file processing method, apparatus, electronic device, and computer-readable storage medium in an embedded system to solve problems in the related art.

[0006] In a first aspect, embodiments of this application provide a file processing method in an embedded system, the method comprising:

[0007] Obtain the supplementary directory, the first target file, and the first archive file; the supplementary directory and the first archive file have the same directory structure; the first archive file is the archive file corresponding to the first root file system; the first root file system is the component that connects the kernel and the application in the embedded system;

[0008] Add the first target file to the supplementary directory;

[0009] According to the preset script, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file;

[0010] The first file system is updated based on the second archive file to obtain the second file system.

[0011] Secondly, embodiments of this application provide a file processing device in an embedded system, the device comprising: an acquisition module, an addition module, an append module, and an update module.

[0012] The acquisition module is used to acquire the supplementary directory, the first target file, and the first archive file; the supplementary directory has the same directory structure as the first archive file; the first archive file is the archive file corresponding to the first root file system; the first root file system is the component that connects the kernel and the application in the embedded system;

[0013] Add a module to add the first target file to the supplement directory;

[0014] The append module is used to append the directory structure of the supplementary directory and the first target file to the end of the first archive file according to a preset script, so as to obtain the second archive file;

[0015] The update module is used to update the first root file system based on the second archive file to obtain the second root file system.

[0016] Thirdly, embodiments of this application also provide an electronic device, including a processor;

[0017] Memory used to store the processor's executable instructions;

[0018] The processor is configured to execute the instructions to implement the method of the first aspect.

[0019] Fourthly, embodiments of this application also provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method of the first aspect.

[0020] This application embodiment obtains a supplementary directory, a first target file, and a first archive file; and limits the directory structure of the supplementary directory to be consistent with that of the first archive file; the first archive file is the archive file corresponding to the first root file system; the first root file system is a component connecting the kernel and the application in the embedded system; this can ensure that the directory structure is consistent, guarantee the file's effectiveness from the source, and prevent the problem of the first target file being appended to the first archive file but not being recognized by the system.

[0021] The first target file is then added to the supplementary directory. All files that need to be appended, i.e., the first target file, can be placed in a separate supplementary directory. For example, debugging tools (debug_monitor.sh), new driver versions (new_driver.ko), or temporary configurations can be placed in the supplementary directory at any time. The first target file is completely decoupled from the Buildroot core configuration and package source code, facilitating independent management and maintenance. There's no need to deeply understand or modify the complex Buildroot configuration system, separating core system building from personalized customization, reducing the cognitive burden of development, and making the project structure clearer and more in line with modular design principles. Furthermore, only the newly added file needs to be copied; there's no need to parse or modify the underlying root file system, and the underlying archive files remain unchanged, facilitating version rollback. It also supports batch updates of multiple files, allowing multiple first target files to be added to the supplementary directory at once.

[0022] Then, according to the preset script, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file. This allows for direct appending of the required target files to the end of the first archive file, providing a convenient method for problem reproduction and fault diagnosis during the testing and verification phase or after field deployment. It eliminates the need for full unpacking and repackaging, complete system reconstruction and flashing, and unnecessary input / output (I / O) operations. This enables rapid injection of debugging scripts or patches and quick updates to the first file system, greatly accelerating development iteration speed and debugging efficiency, and shortening the problem location and repair cycle. Simultaneously, the preset script encapsulates the process of detecting directories, entering directories, and calling cpio commands, improving the automation performance of the embedded system, avoiding build failures due to human error, improving the reliability and consistency of system builds, and reducing the cost and risk of on-site maintenance.

[0023] Finally, based on the second archive file, the first root file system is updated to obtain the second root file system. The first archive file can be replaced with the second archive file containing the first target file, so that the kernel re-decompresses and generates a root file system with new features, rather than modifying the original basic environment. At the same time, while preserving the basic operating capabilities of the embedded device, it carries user-defined core business functions, connects the kernel with new applications, and adapts to the specific hardware or business requirements of the embedded device.

[0024] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart illustrating the steps of a file processing method in an embedded system provided in an embodiment of this application;

[0027] Figure 2 This is a flowchart of another file processing method in an embedded system provided in an embodiment of this application;

[0028] Figure 3 This is a block diagram of a file processing device in an embedded system provided in an embodiment of this application;

[0029] Figure 4 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0031] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0032] In the field of chip-based embedded system development, Buildroot, as a widely used embedded Linux system building tool, can automatically generate a complete system image including the root file system. Among them, rootfs.cpio, as a common root file system archive format, is widely used in scenarios such as initramfs due to its small size and fast startup characteristics. Buildroot is an open-source embedded Linux system building toolset, not a Linux distribution nor a kernel. Its core goal is to automatically and customizable build a complete embedded Linux system, including cross-compilation toolchains, Linux kernels, root file systems (rootfs), bootloaders (such as U-Boot), and finally generate image files that can be directly burned to embedded devices, such as cpio, Fourth Extended Filesystem (ext4), Secure Digital Card (SD) images, etc. Among them, cpio is an archival tool with a long history and crucial importance in Unix and Linux systems, mainly used to create, extract, and manage CPIO-format archival files.

[0033] In related technologies, when developers need to add or update a small number of user-defined files (such as specific configuration files, application programs, or data files, etc.) to the already built rootfs.cpio file system, the following operation process can usually be adopted:

[0034] Unpacking: Use the cpio -imdv <rootfs.cpio command to completely decompress the rootfs.cpio archival file to a temporary directory;

[0035] Modification: Copy the files that need to be added or updated to the corresponding paths in the above temporary directory;

[0036] Repacking: In this temporary directory, execute the find. / | cpio -H newc -o >rootfs.cpio command to repack the entire directory structure to generate a new rootfs.cpio file.

[0037] However, the methods used in these technologies require a complete "unpack-modify-pack" process even when only adding or modifying a single file. This process involves a large number of I / O operations, especially when the root file system contains a lot of data. Unpacking and repackaging are time-consuming, severely impacting the efficiency of development iterations and debugging. Furthermore, the repackaging process relies on the file list generated by the `find` command and the parameters of the `cpio` packing command. Any inappropriate packing parameters (such as file permission handling, archive format, etc.) or unexpected changes to files in the temporary directory can lead to incorrect formatting or incomplete content in the newly generated `rootfs.cpio` file, causing system startup failure and increasing system instability and maintenance costs.

[0038] Against this background, embodiments of this application provide a file processing method in an embedded system, which can eliminate unnecessary I / O operations and improve development iteration speed and debugging efficiency.

[0039] Figure 1 This is a flowchart illustrating the steps of a file processing method in an embedded system provided in an embodiment of this application. Figure 1 As shown, the method may include steps 101-104.

[0040] Step 101: Obtain the supplementary directory, the first target file, and the first archive file.

[0041] In this embodiment, the supplementary directory has the same directory structure as the first archive file; the first archive file is the archive file corresponding to the first root file system; the first archive file can be understood as the basic archive file, i.e., the basic rootfs.cpio file. The first root file system is the component connecting the kernel and the application in the embedded system. After the operating kernel of the embedded system completes its own initialization, it must mount the root file system to read the initialization program from it, and then start the user-mode process management, driver loading, service initialization and other processes to enter an operable system state.

[0042] For example, taking an embedded Linux system as an example, the root file system (rootfs) is the functional carrier and operational foundation of the Linux system. The startup, hardware adaptation, and business operation of the embedded Linux system all depend entirely on the root file system. Without the root file system, the embedded Linux system can only complete kernel initialization and cannot form a complete, runnable, and interactive system. After the kernel completes its own initialization, such as initializing the Central Processing Unit (CPU), memory, and interrupts, it enters a bare kernel state without user-mode functionality. At this time, it cannot recognize peripherals or run any business programs. The kernel must mount the rootfs to read the initialization program (e.g., / sbin / init or / init) and then start user-mode process management, driver loading, service initialization, and other processes. Without the rootfs, the kernel will be stuck in the kernel startup completion stage and cannot enter an operable system state. The embedded device is merely powered hardware without any actual functionality.

[0043] Step 102: Add the first target file to the supplementary directory.

[0044] In this embodiment, the first target file can be understood as a user-defined file, that is, a user-defined file that the developer needs to add or update to the already constructed rootfs.cpio file system. The append directory can be understood as a directory structure used to store all files and directories that the user needs to add to the root file system.

[0045] For example, the new temp_collect.sh script can be placed in the append directory under the subdirectory that matches the base root file system (i.e., the first file system). If the startup script of the base root file system is in / etc / init.d / , the script can be placed under append / etc / init.d / instead of directly in the append root directory.

[0046] Step 103: According to the preset script, append the directory structure of the supplementary directory and the first target file to the end of the first archive file to obtain the second archive file.

[0047] In this embodiment, a build target named `append` can be defined in the top-level Makefile of Buildroot or in the project-specific `package.mk` file. This target triggers the operation of appending files in the `append` directory to the root file system. The pre-defined script can be understood as the `append` target rules (i.e., automated operation logic) pre-written in the Buildroot Makefile. The Makefile can be understood as the top-level build script that drives the entire compilation process. Custom `append` targets can be integrated into the Buildroot build process (e.g., targets that depend on the root file system build); they support manual triggering (`make append`) or automatic triggering (adding `append` to the dependencies of the `all` target); they avoid modifying the native Buildroot build logic, ensuring project maintainability.

[0048] The default script checks if the append directory exists; if it doesn't, the script terminates. If the append directory exists, it checks if it's empty; if so, the script terminates. If the append directory is not empty, it appends the directory structure of the append directory and the first target file to the end of the first archive file, creating a second archive file. For example, you can append only the `etc / init.d / ` directory structure and the first target file `temp_collect.sh` from the append directory to the end of the first archive file; the append directory itself will not be added to the first archive file.

[0049] Step 104: Update the first root file system according to the second archive file to obtain the second root file system.

[0050] In this embodiment, after the embedded system kernel loads the second archive file, it can generate a second root file system (i.e., the updated first root file system) containing the newly added content. The second archive file contains user-added custom files; that is, the second archive file is an archive file with the first target file appended. The second archive file can be understood as an archive carrier of the root file system that the embedded system can directly load and has customization capabilities.

[0051] When an embedded device boots up, the first archive file can be replaced with the second archive file. After the embedded system kernel boots up, it no longer loads the first archive file, but instead loads the second archive file. The kernel can completely decompress the second archive file into memory to generate a brand new root file system (i.e., the second root file system). This environment contains all the basic content of the first root file system (such as / bin / busybox, / etc / init.d / rcS startup scripts), and also adds the relevant content of the first target file. It is equivalent to retaining the basic system and adding custom functions.

[0052] This application embodiment obtains a supplementary directory, a first target file, and a first archive file; and limits the directory structure of the supplementary directory to be consistent with that of the first archive file; the first archive file is the archive file corresponding to the first root file system; the first root file system is a component connecting the kernel and the application in the embedded system; this can ensure that the directory structure is consistent, guarantee the file's effectiveness from the source, and prevent the problem of the first target file being appended to the first archive file but not being recognized by the system.

[0053] The first target file is then added to the supplementary directory. All files that need to be appended, i.e., the first target file, can be placed in a separate supplementary directory. For example, debugging tools (debug_monitor.sh), new driver versions (new_driver.ko), or temporary configurations can be placed in the supplementary directory at any time. The first target file is completely decoupled from the Buildroot core configuration and package source code, facilitating independent management and maintenance. There's no need to deeply understand or modify the complex Buildroot configuration system, separating core system building from personalized customization, reducing the cognitive burden of development, and making the project structure clearer and more in line with modular design principles. Furthermore, only the newly added file needs to be copied; there's no need to parse or modify the underlying root file system, and the underlying archive files remain unchanged, facilitating version rollback. It also supports batch updates of multiple files, allowing multiple first target files to be added to the supplementary directory at once.

[0054] Then, according to the preset script, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file. This allows for direct appending of the required target files to the end of the first archive file, providing a convenient method for problem reproduction and fault diagnosis during the testing and verification phase or after field deployment. It eliminates the need for full unpacking and repackaging, complete system reconstruction and flashing, and unnecessary input / output (I / O) operations. This enables rapid injection of debugging scripts or patches and quick updates to the first file system, greatly accelerating development iteration speed and debugging efficiency, and shortening the problem location and repair cycle. Simultaneously, the preset script encapsulates the process of detecting directories, entering directories, and calling cpio commands, improving the automation performance of the embedded system, avoiding build failures due to human error, improving the reliability and consistency of system builds, and reducing the cost and risk of on-site maintenance.

[0055] Finally, based on the second archive file, the first root file system is updated to obtain the second root file system. The first archive file can be replaced with the second archive file containing the first target file, so that the kernel re-decompresses and generates a root file system with new features, rather than modifying the original basic environment. At the same time, while preserving the basic operating capabilities of the embedded device, it carries user-defined core business functions, connects the kernel with new applications, and adapts to the specific hardware or business requirements of the embedded device.

[0056] Figure 2 This is a flowchart illustrating the steps of another file processing method in an embedded system provided in an embodiment of this application. Figure 2 As shown, the method may include steps 201-214.

[0057] Step 201: Obtain the supplementary directory, the first target file, and the first archive file; the supplementary directory and the first archive file have the same directory structure; the first archive file is the archive file corresponding to the first root file system; the first root file system is the component that connects the kernel and the application in the embedded system.

[0058] In this embodiment, an append directory can be created under the root directory of the embedded system build framework project. The Buildroot project root directory can store directories of core directories such as Makefile, config, package, and configs, i.e., directories built by executing make. The append directory must be created directly here, at the same level as the core directories. The append directory replicates the directory hierarchy of the first file system.

[0059] The specific implementation of step 201 above can be referred to the specific implementation of step 101 above, and will not be repeated here.

[0060] Step 202: Obtain the expected path of the first target file in the second archive file.

[0061] In this embodiment, the expected path can be understood as the absolute path where the first target file is ultimately decompressed into the embedded root file system in the second archive file. This is also a valid path that the embedded system can recognize and call, and the path conforms to the directory specifications of the embedded system. The second archive file is the archive file after appending the first target file. The second archive file can be understood as an archive carrier of the root file system that the embedded system can directly load and that has customized functions.

[0062] For example, taking a Linux system as an embedded system, the directory structure of an embedded system is clearly defined. Embedded systems have fixed storage paths for files with different functions (an industry-standard practice). For instance, "system startup scripts" should be placed under ` / etc / init.d / `, "user-executable tools" under ` / usr / bin / `, and "configuration files" under ` / etc / `. Based on the directory structure of the embedded system, the expected path of the first target file in the second archive file can be determined.

[0063] Step 203: Create a subdirectory under the supplementary directory that corresponds to the expected path;

[0064] Step 204: Add the first target file to the subdirectory.

[0065] In this embodiment, for steps 203-204, the subdirectory can be understood as a directory hierarchy replicated under the supplementary directory after removing the leading root symbol " / " from the expected path. Essentially, it ensures that the internal structure of the supplementary directory is completely aligned with the directory structure of the second archive file. After creating the subdirectory based on the expected path, the first target file can be added to the subdirectory. For example, if a file needs to be added to the / opt / myapp / directory of the target system, the opt / myapp / subdirectory should be created under the append directory and the first target file should be placed there.

[0066] For example, if the expected path is / etc / init.d / , removing the leading " / " will give you "etc / init.d / ". Create this subdirectory in the append directory, that is, perform the operation of creating an etc folder in the append directory and an init.d folder in etc, and finally form the directory structure append / etc / init.d / . Then copy or move the first target file to this directory.

[0067] This embodiment obtains the expected path of the first target file in the second archive file, creates a subdirectory corresponding to the expected path in the supplementary directory, and then adds the first target file to the subdirectory. This ensures that the actual path of the first target file in the second archive file is completely consistent with the valid path of the embedded system, preventing the kernel from recognizing and calling the second archive file even if the first target file is successfully appended, thus avoiding invalid operations where the file is appended but cannot be used. Simultaneously, the subdirectories in the supplementary directory completely correspond to the expected path of the second archive file, allowing the first target file to accurately adapt to the path specifications of the embedded system. The pre-set script does not require additional modification to the path logic, proactively avoiding human error and improving the success rate of the append operation.

[0068] Step 205: According to the preset script, call the append command of the archiving tool in the embedded system to put the archiving tool in the embedded system into append mode.

[0069] Step 206: When the archiving tool in the embedded system is in append mode, append the directory structure of the supplementary directory and the first target file to the end of the first archive file to obtain the second archive file.

[0070] In this embodiment, for steps 205-206, the archiving tool in the embedded system is a cpio tool dependent on the embedded system build environment, such as the cpio tool dependent on the development host or personal computer (PC). The cpio tool is necessary for Buildroot to build rootfs.cpio and is adapted to the embedded cpio archive format. The preset script can execute the core command parameters that trigger append mode, that is, call the append command of the archiving tool in the embedded system, so that the cpio tool enters append mode.

[0071] The default script can automatically switch to the append directory first, ensuring that the cpio tool scans the contents of the append directory. In append mode, the cpio tool can scan all the contents of the append directory and write them directly to the end of the byte stream of the first archive file. The entire process only writes new content and does not read or modify the existing byte stream.

[0072] For example, the core command parameter for append mode is the -A parameter of the cpio tool. After triggering the -A parameter, the cpio tool enters append mode. Append mode can be understood as a dedicated running state of the cpio tool, used only to incrementally add content to the end of an existing cpio archive file without decompressing the original archive file.

[0073] Before entering append mode, the cpio tool can perform a pre-verification, which checks whether the first archive file exists and whether it is in the embedded kernel-compatible newc format. If the file does not exist or the format is incorrect, the cpio tool can terminate and report an error to avoid invalid operations. If the first archive file exists and is in the embedded kernel-compatible newc format, it can check whether the first archive file is writable to ensure that there is permission to append content to its end.

[0074] After successful verification, the cpio tool enters append mode and can scan all contents within the append directory. For example, it first identifies the directory structure, scanning up to the level of etc / →etc / init.d / ; then it identifies the first target file, scanning up to temp_collect.sh under etc / init.d / . The cpio tool can then directly write all the scanned contents of the append directory to the end of the byte stream of the first archive file.

[0075] This embodiment, based on a preset script, invokes the append command of the archiving tool in the embedded system, putting the archiving tool into append mode. In append mode, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file, resulting in a second archive file. This approach allows for a unified invocation of the append command, fixing the parameters that trigger append mode and ensuring the basic content of the first archive file remains intact. Developers do not need to manually input append commands in the terminal, and they do not need to concern themselves with the details of the packaging commands, reducing the risk of human error and improving the reliability and consistency of the system build. Furthermore, append mode eliminates the need to decompress the first archive file; the contents of the supplementary directory are directly written to the end of the file, shortening the iteration cycle of the embedded system and improving debugging efficiency.

[0076] Optionally, step 206 above may include sub-steps 2061-2062.

[0077] Sub-step 2061: When the archiving tool in the embedded system is in append mode, traverse all first target files in the supplementary directory and package the directory structure of the supplementary directory and the first target files into archive data fragments.

[0078] In this embodiment, when the archiving tool in the embedded system is in append mode, the preset script can automatically switch the working directory to the append directory to ensure that the cpio tool scans the contents of the append directory. The cpio tool can traverse the append directory according to the directory hierarchy priority. For example, it first identifies the directory structure, such as scanning to / etc / and then scanning init.d / under / etc / , completely replicating the hierarchy of / etc / init.d / ; then it identifies the first target file, such as scanning temp_collect.sh and hum_collect.sh under / etc / init.d / , and records the file permissions, owner user or group, etc., to ensure that the appended file can be executed normally. After the scan is completed, cpio can call the -o and -H newc parameters to integrate the scanned directory structure and the first target file into a temporary archive data fragment in memory. This fragment can be in byte stream form. This fragment can be understood as an independent, small cpio archive file containing only the newly added content. Here, -o indicates the parameter to trigger the packaging command, and -H newc is used to specify the embedded compatibility format.

[0079] Sub-step 2062: Append the archived data fragments to the end of the first archive file to obtain the second archive file.

[0080] In this embodiment, the cpio tool first reads the byte stream information of the first archive file, accurately locating the last byte position of the file to ensure that the appended content does not overwrite the original content. cpio then directly writes the byte stream of the aforementioned archived data fragment to the end of the first archive file. The entire process does not open or decompress the first archive file; it only appends the byte stream without reading or modifying the original byte stream.

[0081] In this embodiment, when the archiving tool in the embedded system is in append mode, it traverses all first target files in the supplementary directory, packages the directory structure of the supplementary directory and the first target files into archive data fragments, and appends these archive data fragments to the end of the first archive file to obtain the second archive file. The supplementary directory can be traversed hierarchically by directory → file, replicating the complete directory structure while preserving metadata such as script executable permissions and owner. Furthermore, the packaged archive data fragments are in the embedded standard format, ensuring that when the kernel loads the second archive file, it can directly parse the newly added first target file content, thus enabling the second archive file obtained after appending the first target file to be executed correctly by the kernel. Simultaneously, because only incremental appending is performed, if an error occurs in the second archive file, simply reverting to the first archive file is sufficient to restore the basic system, without needing to recompile the entire root file system, improving the ease of maintaining the embedded system.

[0082] Step 207: Update the first file system according to the second archive file to obtain the second file system.

[0083] The specific implementation of step 207 above can be referred to the specific implementation of step 104 above, and will not be repeated here.

[0084] Optionally, the above method may also include steps 208-211.

[0085] Step 208: Start the embedded system based on the second root file system.

[0086] In this embodiment, after the embedded device is powered on, the kernel can load the second archive file from a specified storage location, verify that the format is an embedded compatible format, and then decompress the second archive file into memory or local storage to generate a second root file system. Subsequently, the kernel executes the initialization process (e.g., calling / sbin / init), loads the startup script in the second root file system, completes hardware initialization, service startup, and other operations based on the second root file system, and finally enters the runnable user mode.

[0087] Step 209: Verify that the first target file exists in the root directory of the embedded system.

[0088] Step 210: If yes, then the first target file has been added successfully.

[0089] Step 211: If not, then the addition of the first target file has failed. Proceed to obtain the supplementary directory, the first target file, and the first archive file.

[0090] In this embodiment, steps 209-211 verify whether the first target file exists in the root directory of the embedded system. The core of the verification is to confirm that the file path exists precisely, and not just exists within the embedded system. That is, whether the first target file exists in the root directory of the embedded system can be understood as whether the first target file exists in the root file system directory corresponding to the expected path.

[0091] If the first target file exists in the root directory of the embedded system, the addition of the first target file is successful, and the process of appending the first target file can be terminated. If the first target file does not exist in the root directory of the embedded system, the addition of the first target file is considered a failure. In this case, the steps of obtaining the supplementary directory, the first target file, and the first archive file can be returned, and the entire process can be re-executed. Alternatively, the process of appending the first target file can be terminated to investigate the cause of the failure and correct the problem.

[0092] For example, based on the second root file system, after the embedded system starts, the existence of the first target file in the root directory of the embedded system can be verified by checking the filename of the first target file, the consistency between the directory where the first target file is located and the expected path, and the file metadata of the first target file (such as executable permissions). For instance, if it is determined that the filename of the first target file is accurate, without any extra suffixes or spelling errors, the directory where the first target file is located is completely consistent with the expected path, and the file metadata of the first target file meets the executable requirements of the startup script, then it is determined that the first target file exists in the root directory of the embedded system, thus confirming that the first target file has been successfully added.

[0093] This embodiment can start the embedded system based on the second root file system; then verify whether the first target file exists in the root directory of the embedded system; if so, it is determined that the first target file was added successfully; if not, it is determined that the first target file was added unsuccessfully, and proceed to obtain the supplementary directory, the first target file, and the first archive file. After starting the embedded system based on the second root file system, it can verify whether the appended first target file has correctly appeared in the expected location of the root file system, thereby quickly locating the fault when a failure occurs, without needing to deeply debug the application logic, avoiding the system continuing to run in an erroneous state, preventing the system from being in an unstable state, and improving the reliability of the embedded system.

[0094] Optionally, the above method may also include steps 212-214.

[0095] Step 212: Create a manifest file in the supplementary directory.

[0096] The manifest file is used to record the first target file that has been appended to the end of the first archive file.

[0097] For example, the manifest file may record the filename of the first target file that has been appended to the end of the first archive file. For instance, if the manifest file records the filenames of first target file 1, first target file 2, and first target file 3, it means that first target file 1, first target file 2, and first target file 3 have all been appended to the end of the first archive file.

[0098] Step 213: Determine the second target file from the first target file based on the manifest file.

[0099] Step 214: According to the preset script, add the directory structure of the supplementary directory and the second target file to the end of the first archive file to obtain the second archive file.

[0100] In this embodiment, for steps 213-214, the second target file can be understood as the first target file that was not appended to the end of the first archive file. After traversing the supplementary directory, the filenames of the first target files stored in the supplementary directory and the files recorded in the manifest file can be compared. Based on the comparison results, the second target file, i.e., the first target file that was not appended to the end of the first archive file, is selected; that is, the first target file that was not recorded in the manifest file. Subsequently, according to a preset script, the directory structure of the supplementary directory and the second target file are added to the end of the first archive file to obtain the second archive file.

[0101] Based on the above embodiments, exemplarily, if the manifest file records the filenames of first target file 1, first target file 2, and first target file 3, then the supplementary directory is traversed to determine that first target file 2, first target file 3, first target file 4, and first target file 5 are stored in the supplementary directory. The filenames of each first target file stored in the supplementary directory can be compared with the filenames of the first target files recorded in the manifest file to determine that first target file 2 and first target file 3 have been appended to the end of the first archive file, while first target file 4 and first target file 5 have not been appended to the end of the first archive file; that is, first target file 4 and first target file 5 are second target files. Subsequently, according to a preset script, the directory structure of the supplementary directory and first target file 4 and first target file 5 are added to the end of the first archive file to obtain the second archive file.

[0102] This embodiment creates a manifest file in the supplementary directory. Based on the manifest file, a second target file is determined in the first target file. Then, according to a preset script, the directory structure of the supplementary directory and the second target file are appended to the end of the first archive file to obtain the second archive file. This ensures that files already appended to the end of the first archive file will not be appended again, guaranteeing that the same file is appended only once. This avoids the overwriting chaos caused by multiple appends of the same file, improves the success rate of appending target files, and further enhances the reliability of the embedded system.

[0103] In one specific embodiment, the implementation process of a Makefile target may include:

[0104] append:

[0105] @echo "Starting file append operation..."

[0106] @if [ ! -d "$(APPEND_DIR)" ]; then \

[0107] echo "Error: append directory does not exist"; \

[0108] exit 1; \

[0109] fi

[0110] @if [ ! -f "$(ROOTFS_CPIO)" ]; then \

[0111] echo "Error: rootfs.cpio file does not exist. Please perform a full build first.";

[0112] exit 1; \

[0113] fi

[0114] @if [ -z "$(shell ls -A $(APPEND_DIR))" ]; then \

[0115] echo "Warning: append directory is empty, no need to append";

[0116] exit 0; \

[0117] fi

[0118] @echo "Appendix detected, processing..."

[0119] @cd $(APPEND_DIR)&&\

[0120] find . -print0 | cpio --null -H newc -o -A -F $(ROOTFS_CPIO)

[0121] @echo "File append complete! New rootfs.cpio generated"

[0122] In summary, this application embodiment obtains a supplementary directory, a first target file, and a first archive file; and limits the directory structure of the supplementary directory to be consistent with that of the first archive file; the first archive file is the archive file corresponding to the first root file system; the first root file system is a component connecting the kernel and the application in the embedded system; this ensures that the directory structure is consistent, guarantees the file's effectiveness from the source, and prevents the problem of the first target file being appended to the first archive file but not being recognized by the system.

[0123] The first target file is then added to the supplementary directory. All files that need to be appended, i.e., the first target file, can be placed in a separate supplementary directory. For example, debugging tools (debug_monitor.sh), new driver versions (new_driver.ko), or temporary configurations can be placed in the supplementary directory at any time. The first target file is completely decoupled from the Buildroot core configuration and package source code, facilitating independent management and maintenance. There's no need to deeply understand or modify the complex Buildroot configuration system, separating core system building from personalized customization, reducing the cognitive burden of development, and making the project structure clearer and more in line with modular design principles. Furthermore, only the newly added file needs to be copied; there's no need to parse or modify the underlying root file system, and the underlying archive files remain unchanged, facilitating version rollback. It also supports batch updates of multiple files, allowing multiple first target files to be added to the supplementary directory at once.

[0124] Then, according to the preset script, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file. This allows for direct appending of the required target files to the end of the first archive file, providing a convenient method for problem reproduction and fault diagnosis during the testing and verification phase or after field deployment. It eliminates the need for full unpacking and repackaging, complete system reconstruction and flashing, and unnecessary input / output (I / O) operations. This enables rapid injection of debugging scripts or patches and quick updates to the first file system, greatly accelerating development iteration speed and debugging efficiency, and shortening the problem location and repair cycle. Simultaneously, the preset script encapsulates the process of detecting directories, entering directories, and calling cpio commands, improving the automation performance of the embedded system, avoiding build failures due to human error, improving the reliability and consistency of system builds, and reducing the cost and risk of on-site maintenance.

[0125] Finally, based on the second archive file, the first root file system is updated to obtain the second root file system. The first archive file can be replaced with the second archive file containing the first target file, so that the kernel re-decompresses and generates a root file system with new features, rather than modifying the original basic environment. At the same time, while preserving the basic operating capabilities of the embedded device, it carries user-defined core business functions, connects the kernel with new applications, and adapts to the specific hardware or business requirements of the embedded device.

[0126] This application also provides a file processing device in an embedded system. Figure 3 This is a block diagram of a file processing device in an embedded system provided in an embodiment of this application. Figure 3As shown, the file processing device 300 in the embedded system may include: an acquisition module 301, an addition module 302, an append module 303, and an update module 304.

[0127] The acquisition module 301 is used to acquire the supplementary directory, the first target file, and the first archive file; the supplementary directory has the same directory structure as the first archive file; the first archive file is the archive file corresponding to the first root file system; the first root file system is the component that connects the kernel and the application in the embedded system;

[0128] Add module 302 to add the first target file to the supplement directory;

[0129] The append module 303 is used to append the directory structure of the supplementary directory and the first target file to the end of the first archive file according to a preset script, so as to obtain the second archive file;

[0130] Update module 304 is used to update the first root file system based on the second archive file to obtain the second root file system.

[0131] Optionally, module 302 is added, specifically used to obtain the expected path of the first target file in the second archive file; create a subdirectory corresponding to the expected path in the supplementary directory; and add the first target file to the subdirectory.

[0132] Optionally, the append module 303 is specifically used to call the append command of the archive tool in the embedded system according to a preset script, so that the archive tool in the embedded system is in append mode; when the archive tool in the embedded system is in append mode, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file.

[0133] Optionally, the append module 303 is specifically used to, when the archiving tool in the embedded system is in append mode, traverse all first target files in the supplementary directory, package the directory structure of the supplementary directory and the first target files into archive data fragments; and append the archive data fragments to the end of the first archive file to obtain the second archive file.

[0134] Optionally, such as Figure 3 As shown, the file processing device 300 in the embedded system may further include a processing module 305.

[0135] The processing module 305 is used to start the embedded system according to the second root file system; verify whether the first target file exists in the root directory of the embedded system; if it does, it determines that the first target file has been added successfully; if not, it determines that the first target file has failed to be added, and proceeds to obtain the supplementary directory, the first target file and the first archive file.

[0136] Optionally, the processing module 305 is also used to create a manifest file in the supplementary directory; the manifest file is used to record the first target file that has been added to the end of the first archive file; based on the manifest file, a second target file is determined in the first target file; the second target file is the first target file that has not been added to the end of the first archive file; the append module 303 is specifically used to add the directory structure of the supplementary directory and the second target file to the end of the first archive file according to a preset script to obtain the second archive file.

[0137] Optionally, module 301 is used to create an additional directory in the root directory of the embedded system building framework project.

[0138] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0139] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0140] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0141] This application also provides a file processing apparatus in an embedded system, including a memory and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by one or more processors, the one or more programs comprising methods for performing the methods described in one or more of the above embodiments.

[0142] This application also provides an electronic device. See also... Figure 4 , Figure 4 This is a block diagram illustrating an electronic device 400 according to an exemplary embodiment. For example, the electronic device 400 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0143] Reference Figure 4 The electronic device 400 may include one or more of the following components: processing component 402, memory 404, power supply component 406, multimedia component 408, audio component 410, input / output (I / O) interface 412, sensor component 414, and communication component 416.

[0144] Processing component 402 typically controls the overall operation of electronic device 400, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 402 may include one or more processors 420 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 402 may include one or more modules to facilitate interaction between processing component 402 and other components. For example, processing component 402 may include a multimedia module to facilitate interaction between multimedia component 408 and processing component 402.

[0145] Memory 404 is used to store various types of data to support the operation of electronic device 400. Examples of such data include instructions for any application or method operating on electronic device 400, contact data, phonebook data, messages, pictures, multimedia, etc. Memory 404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0146] Power supply component 406 provides power to various components of electronic device 400. Power supply component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 400.

[0147] Multimedia component 408 includes a screen that provides an output interface between the electronic device 400 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 408 includes a front-facing camera and / or a rear-facing camera. When the electronic device 400 is in an operating mode, such as a shooting mode or a multimedia mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0148] Audio component 410 is used to output and / or input audio signals. For example, audio component 410 includes a microphone (MIC) used to receive external audio signals when electronic device 400 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 404 or transmitted via communication component 416. In some embodiments, audio component 410 also includes a speaker for outputting audio signals.

[0149] I / O interface 412 provides an interface between processing component 402 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0150] Sensor assembly 414 includes one or more sensors for providing state assessments of various aspects of electronic device 400. For example, sensor assembly 414 may detect the on / off state of electronic device 400, the relative positioning of components such as the display and keypad of electronic device 400, changes in position of electronic device 400 or a component of electronic device 400, the presence or absence of user contact with electronic device 400, orientation or acceleration / deceleration of electronic device 400, and temperature changes of electronic device 400. Sensor assembly 414 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 414 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 414 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0151] Communication component 416 facilitates wired or wireless communication between electronic device 400 and other devices. Electronic device 400 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 416 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 416 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0152] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement the methods provided in the embodiments of this application.

[0153] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 404 including instructions, which can be executed by a processor 420 of an electronic device 400 to perform the above-described method. For example, the non-transitory storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0154] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0155] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0156] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A file processing method in an embedded system, characterized in that, The method includes: Obtain the supplementary directory, the first target file, and the first archive file; the supplementary directory has the same directory structure as the first archive file; the first archive file is the archive file corresponding to the first root file system; the first root file system is the component connecting the kernel and the application in the embedded system; Add the first target file to the supplementary directory; According to the preset script, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file; The first root file system is updated based on the second archive file to obtain the second root file system; The step of appending the directory structure of the supplementary directory and the first target file to the end of the first archive file according to a preset script to obtain a second archive file includes: According to the preset script, the append command of the archiving tool in the embedded system is invoked, so that the archiving tool in the embedded system is in append mode; When the archiving tool in the embedded system is in append mode, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file.

2. The method according to claim 1, characterized in that, Adding the first target file to the supplementary directory includes: Obtain the expected path of the first target file in the second archive file; Create a subdirectory under the supplementary directory that corresponds to the expected path; Add the first target file to the subdirectory.

3. The method according to claim 1, characterized in that, When the archiving tool in the embedded system is in append mode, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file, including: When the archiving tool in the embedded system is in append mode, it traverses all the first target files under the supplementary directory and packages the directory structure of the supplementary directory and the first target files into archived data fragments. The archived data fragments are appended to the end of the first archived file to obtain the second archived file.

4. The method according to claim 1, characterized in that, The method further includes: The embedded system is started according to the second root file system; Verify that the first target file exists in the root directory of the embedded system; If so, then the first target file has been added successfully; If not, it is determined that the first target file failed to be added, and the process proceeds to obtaining the supplementary directory, the first target file, and the first archive file.

5. The method according to claim 1, characterized in that, The method further includes: Create a manifest file in the supplementary directory; the manifest file is used to record the first target files that have been added to the end of the first archive file; Based on the manifest file, a second target file is determined in the first target file; the second target file is the first target file that is not appended to the end of the first archive file; The step of adding the directory structure of the supplementary directory and the first target file to the end of the first archive file according to a preset script to obtain a second archive file includes: According to the preset script, the directory structure of the supplementary directory and the second target file are added to the end of the first archive file to obtain the second archive file.

6. The method according to claim 1, characterized in that, The process of obtaining the supplementary catalog includes: Create the supplementary directory in the root directory of the embedded system building framework project.

7. A file processing device in an embedded system, characterized in that, The device includes: The acquisition module is used to acquire a supplementary directory, a first target file, and a first archive file; the supplementary directory has the same directory structure as the first archive file; the first archive file is an archive file corresponding to a first root file system; the first root file system is a component in the embedded system that connects the kernel and the application program; An add module is used to add the first target file to the supplementary directory; The append module is used to append the directory structure of the supplementary directory and the first target file to the end of the first archive file according to a preset script, so as to obtain a second archive file; The update module is used to update the first root file system according to the second archive file to obtain the second root file system; The additional module is specifically used for: According to the preset script, the append command of the archiving tool in the embedded system is invoked, so that the archiving tool in the embedded system is in append mode; When the archiving tool in the embedded system is in append mode, the directory structure of the supplementary directory and the first target file are appended to the end of the first archive file to obtain the second archive file.

8. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1 to 6.

Images