A virtual file system in an embedded bare machine environment and an implementation method thereof

Abstract

The application discloses a kind of virtual file systems in embedded bare machine environment and implementation method, belong to embedded real-time operating system and the technical field of file management in bare machine application, include: initialization global management resource containing file system node table;Obtain the registration resource containing standardized operation interface set, mounting path, flag and context pointer;Based on the resource, file system instance is registered to node table to generate VFS node;Response application access request, according to target path matching target VFS node;Through the operation set associated with the node, the request is forwarded to underlying file system execution.The application realizes the unified transparent access to heterogeneous file system in bare machine environment through lightweight virtualization layer and standardized interface, solves the problem of high adaptation cost and fragmentation of file system interface in embedded field.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of embedded real-time operating system and file management in bare machine application, and particularly relates to a virtual file system in an embedded bare machine environment and an implementation method. BACKGROUND

[0002] In the prior art, various file systems such as FatFS, YAFFS, SPIFFS, NFS coexist in the embedded real-time scene, but their operation interfaces are different, resulting in high system integration complexity and poor expansibility, and there are significant differences between block file systems and byte file systems in structure and access characteristics, which are difficult to unify and efficiently manage. Therefore, a virtual file system capable of providing a unified operation interface for the above-mentioned heterogeneous file systems is urgently needed, and a standard adaptation integration method is defined to simplify the access process of different storage devices, peripherals and network resources, and to realize effective integration of block file systems and byte file systems in architecture and access level.

[0003] At present, the embedded Internet of Things field mainly faces the following technical defects in file system management: There is a lack of simple and efficient general VFS framework, resulting in serious ecological fragmentation. The current embedded field software and hardware platform is highly fragmented, and the file system interfaces and implementations provided by different chip manufacturers and RTOS (such as FreeRTOS, RT-Thread, Zephyr, etc.) are different. For example, although ARM Mbed OS provides a unified file system interface, there are significant differences in API design between it and the FatFS component popular in the FreeRTOS community, forcing developers to maintain multiple sets of code for different platforms, which cannot achieve "one development, multiple deployment", and seriously reduces software reuse and development efficiency.

[0004] The API interfaces of file systems of different storage media are different, which significantly increases the development cost and adaptation difficulty of developers. Even for the same platform, commonly used embedded file systems such as FAT (FatFS), log type (SPIFFS / LittleFS) and network file system (NFS) have great differences in the semantics, parameters and return values of their APIs. For example, the f_open function has many parameters in FatFS, but it is relatively simple in SPIFFS. Such subtle differences can easily lead to misuse by developers, causing memory leaks, data corruption and other errors. Developers need to learn and adapt a new API every time they change a storage medium (such as from SPI FLASH to SD card), and the adaptation work is tedious and error-prone.

[0005] Existing VFS functionalities are limited, failing to abstract access to various peripherals and restricting application scenario expansion. Traditional VFS concepts are typically confined to storage devices. However, in IoT scenarios, many peripherals (such as sensors and actuators) can be abstracted as "files" for read and write operations (e.g., read( / dev / sensor / temperature), write( / dev / actuator / led)). Existing solutions lack standardized support for this broad "file" access, forcing developers to directly call underlying hardware drivers, resulting in strong coupling between application layer code and hardware, hindering flexible expansion and reuse. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention proposes a virtual file system and its implementation method in an embedded bare-metal environment, thereby resolving the issues present in the prior art.

[0007] To achieve the above objectives, the present invention provides a method for implementing a virtual file system in an embedded bare-metal environment, comprising: Initialize the global management resources of the Virtual File System (VFS), which include a file system node table for managing file system instances; Obtain the registration resources of the underlying file system instance to be accessed; register the underlying file system instance to be accessed to the file system node table based on the registration resources, and generate the corresponding VFS node; wherein, the registration resources include: a standardized operation set conforming to the HzptVfsFsOps structure and the HzptVfsDirOps structure definition, the mount path of the file system, the file system flag bit and the private context pointer. In response to a file access request from the application layer, the corresponding target VFS node is matched from the file system node table based on the target path in the file access request. By using the standardized set of operations associated with the target VFS node, the file access request is forwarded to the target underlying file system for execution, thereby enabling access to heterogeneous underlying file systems through a unified interface.

[0008] Optionally, the HzptVfsInit function is called to initialize the global management resources of the virtual file system (VFS), including: Create and initialize the file system node table; in the HzptVfsInit function, call the HzptVfsOpsInit function to create an operation memory pool to manage the memory allocation of the HzptVfsFsOps and HzptVfsDirOps structures; initialize the VFS lock for multi-threaded synchronization; perform a memory zeroing operation on the file descriptor table to initialize all file descriptors to an unused state.

[0009] Optionally, obtain the standardized set of operations that conforms to the definitions of the HzptVfsFsOps and HzptVfsDirOps structures, including: The HzptVfsFsOps structure encapsulates file-level operations, and its members are pointers to file-level operation functions. Each file-level operation provides a function version with a context pointer parameter and a function version without a context pointer parameter through a union. The HzptVfsDirOps structure encapsulates directory-level operations, and its members are pointers to directory-level operation functions. Each directory-level operation provides a function version with a context pointer parameter and a function version without a context pointer parameter through a union.

[0010] Optionally, the HzptVfsFsOps structure further includes a select pointer that points to the HzptVfsSelectOps structure; the HzptVfsSelectOps structure encapsulates the selection operation, and its members are pointers to selection operation functions used to support multiplexing operations.

[0011] Optionally, based on the registered resources, the underlying file system instance to be accessed is registered to the file system node table to generate the corresponding VFS node, including: Call the HzptVfsRegister function, passing in a pointer to the standardized operation set, the private context pointer, the mount path, and the file system flags; Based on whether the file system flags contain the HzptVfs_FLAGS_STATIC flag, determine whether to copy the standardized operation set to the operation memory pool using the HzptVfsOpsCopy function; Traverse the file system node table to find unused entries with a usage status marker of 0; The mount path, the file system flag, the processed operation set pointer, and the private context pointer are filled into the found entry, and the usage status flag is set to 1. At the same time, the index of the corresponding entry is recorded, and the corresponding VFS node is generated.

[0012] Optionally, matching the corresponding target VFS node from the file system node table based on the target path in the file access request includes: Traverse the file system node table to obtain each VFS node; Check the usage status flag of each VFS node and filter out all nodes marked as used as candidate nodes; For each candidate node, the mount path stored in its path field is used as a prefix and compared with the target path in the file access request to determine whether the target path is prefixed with the corresponding mount path. From all candidate nodes that meet the prefix matching condition, select the node with the longest mount path and determine it as the target VFS node.

[0013] Optionally, file access requests can be forwarded to the target underlying file system for execution via a standardized set of operations associated with the target VFS node, including: The HzptVfsTranslatePath function is called to convert the target path into a relative path within the underlying file system based on the path field and path length field of the target VFS node; and the corresponding function in the standardized operation set is called according to the file system flag bit of the target VFS node.

[0014] Optionally, depending on whether the target VFS node's file system flag field contains the HzptVfs_FLAGS_CONTEXT_PTR flag, it is determined whether a context pointer needs to be passed. If the HzptVfs_FLAGS_CONTEXT_PTR flag is included, the corresponding function version with a context pointer parameter in the HzptVfsFsOps or HzptVfsDirOps structure is called, and the private context pointer is passed in. If the HzptVfs_FLAGS_CONTEXT_PTR flag is not included, the corresponding function version without a context pointer parameter is called.

[0015] Optionally, after successfully opening a file using the standardized operation set and obtaining the file identifier returned by the underlying file system, the HzptVfsRegisterWithFd function is called; The HzptVfsRegisterWithFd function allocates a file descriptor node structure in the file descriptor table; sets the index field of the allocated file descriptor node structure to the index of the file system node structure corresponding to the opened file; records the file identifier returned by the underlying file system in the file identifier field of the allocated file descriptor node structure; and returns the file descriptor generated based on the allocated file descriptor node structure and valid at the VFS layer to the application layer.

[0016] The present invention also provides a virtual file system in an embedded bare-metal environment for performing the above-described method, comprising: The global management resource initialization module is used to initialize the global management resources of the virtual file system (VFS), wherein the global management resources include a file system node table for managing file system instances; The registration resource processing and node management module is used to obtain the registration resources of the underlying file system instance to be connected, and register the underlying file system instance to the file system node table based on the registration resources to generate the corresponding VFS node; wherein, the registration resources include: a standardized operation set conforming to the HzptVfsFsOps structure and the HzptVfsDirOps structure definition, the mount path of the file system, the file system flag bit and the private context pointer; The request routing and execution module is used to respond to file access requests from the application layer, match the corresponding target VFS node from the file system node table according to the target path in the file access request, and forward the file access request to the target underlying file system for execution through the standardized operation set associated with the target VFS node.

[0017] Compared with the prior art, the present invention has the following advantages and technical effects: The virtual file system implemented based on this invention can achieve a file system scheme similar to that in the Linux kernel in embedded RTOS and bare-metal environments, and is easier to implement and deploy. In RTOS and bare-metal development environments, the fragmented file system ecosystem (FatFS, SPIFFS, NFS) is not conducive to developers' abstraction and unification of software. This invention provides a unified abstract interface for accessing different file systems in both RTOS and bare-metal environments. Based on this virtual file system (VFS), the functionality of monitoring multiple file descriptors can be further extended, enabling parallel processing capabilities that are only useful in server systems to be achieved in RTOS and bare-metal development environments. Attached Figure Description

[0018] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a diagram of the virtual file system architecture according to an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the process of adapting a file system to VFS according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating how a specific file system is adapted to a virtual file system, according to an embodiment of the present invention. Detailed Implementation

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0021] Example 1 In existing technologies, various file systems such as FatFS, YAFFS, SPIFFS, and NFS coexist in embedded real-time scenarios. However, their operation interfaces differ, leading to high system integration complexity and poor scalability. Furthermore, block file systems and byte file systems differ significantly in structure and access characteristics, making unified and efficient management difficult. Therefore, there is an urgent need for a virtual file system that can provide a unified operation interface for the aforementioned heterogeneous file systems, and to define a standard adaptation and integration method to simplify the access process of different storage devices, peripherals, and network resources, while achieving effective integration of block file systems and byte file systems at the architectural and access levels.

[0022] like Figure 1 As shown, this embodiment provides a lightweight virtual file system in an embedded bare-metal environment. The core is to achieve the goal of "unified operation of upper-layer applications and adaptation of different storage devices / file systems at the lower layer" through a layered design.

[0023] The global management resource initialization module is used to initialize the global management resources of the virtual file system (VFS), wherein the global management resources include a file system node table for managing file system instances; The registration resource processing and node management module is used to obtain the registration resources of the underlying file system instance to be connected, and register the underlying file system instance to the file system node table based on the registration resources to generate the corresponding VFS node; wherein, the registration resources include: a standardized operation set conforming to the HzptVfsFsOps structure and the HzptVfsDirOps structure definition, the mount path of the file system, the file system flag bit and the private context pointer; The request routing and execution module is used to respond to file access requests from the application layer, match the corresponding target VFS node from the file system node table according to the target path in the file access request, and forward the file access request to the target underlying file system for execution through the standardized operation set associated with the target VFS node.

[0024] Specifically, it includes: (1) Application layer: Applications based on file interfaces; Function: Directly call standard file interfaces (such as open / read / write) to perform file operations without needing to care about the differences in the underlying storage device or file system.

[0025] Features: Enables file operations across storage devices through a unified interface, resulting in higher development efficiency.

[0026] (2) Intermediate abstraction layer: HzptVfs-posix+HzptVfs; These two layers are the core abstraction layers of the Virtual File System (VFS): HzptVfs-posix: Provides a POSIX standard file interface (such as conforming to Linux / UNIX file operation specifications), and is the interaction entry point between the application layer and the virtual file system. It is responsible for forwarding the application's file operation requests to HzptVfs.

[0027] HzptVfs: The core abstraction layer of the virtual file system, which shields the differences between the underlying storage devices and file systems, provides a unified interface to the top, and adapts to different specific file systems (such as FAT and SPIFFS) to the bottom.

[0028] (3) Device adaptation layer: HzptVfs-dev and its sub-modules; This layer is responsible for interfacing with specific file systems and hardware drivers, enabling adaptation to different file systems / storage devices: HzptVfs-dev: The main entry point for device adaptation, managing the binding of various file systems and hardware drivers.

[0029] Specific file system submodules: HzptVfs-fat: Adapts to the FAT file system (universal, compatible with Windows / Linux, suitable for storage devices such as SD cards).

[0030] HzptVfs-spiffs: Adapts to the SPIFFS file system (lightweight, supports wear leveling, designed specifically for SPI NORFlash).

[0031] HzptVfs_null: Empty file system adaptation (typically used for debugging or scenarios without actual storage).

[0032] Hardware driver submodule: fsl_sdmmc: SD / MMC card driver (interfaces with SD card hardware to enable read and write operations on the SD card).

[0033] sfud: Universal serial Flash driver (supports SPI / QSPI interface Flash, automatically adapts to different brands / models of Flash, reducing hardware dependency risk).

[0034] (4) Underlying hardware: SoC; Function: Refers to the System on Chip (SoC) of an embedded system. It is the hardware foundation of the entire architecture and provides interfaces such as SPI and SDIO for connecting storage devices (such as Flash and SD cards).

[0035] Overall workflow: When an application calls `:write` to write a file: The application initiates a request through the POSIX interface of HzptVfs-posix; HzptVfs forwards the request to the corresponding file system (such as HzptVfs-fat); HzptVfs-fat operates the SD card hardware through the fsl_sdmmc driver; finally, the actual storage read and write is completed by the hardware interface of the SoC.

[0036] The core value of this architecture is decoupling the upper-layer application from the lower-layer hardware: the application only needs to write one set of code to adapt to different storage devices such as SD cards and SPI Flash, while supporting different file systems such as FAT and SPIFFS.

[0037] like Figure 2 As shown, this embodiment provides a method for implementing a lightweight virtual file system in an embedded bare-metal environment, including: (I) VFS Environment Initialization Phase: This phase mainly initializes VFS memory resources and multi-threaded locks. The specific steps are as follows: 101: Developers initiate the VFS initialization process by calling the `HzptVfsInit` function. This function first calls the `HzptVfsOpsInit` function to create an operation memory pool (`ops_mem_pool`), which manages the memory allocation of file system operation structures. If memory pool creation fails, an out-of-memory error (`HzptVfs_ERR_NO_MEM`) is returned. The `HzptVfsInit` function initializes the entire VFS, including the initialization of file system nodes and POSIX interfaces.

[0038] 102: After completing the initialization of the memory pool, the HzptVfsInit function initializes the VFS lock (vfs_lock) for multi-threaded synchronization and clears the file descriptor table (vfs_fd_table) to ensure that all file descriptors are in an unused state in the initial state; after completion, it returns the initialization success flag (HzptVfs_SUCCESS).

[0039] (II) File System Resource Preparation Phase: This phase primarily involves adapting the file system to be registered to the VFS (Virtual File System) interface, ensuring it can be correctly mounted and respond to upper-layer operations. The specific steps are as follows: 201: The file system to be registered (such as fatfs, Yaffs, nfs) must provide an operation set that conforms to the HzptVfsFsOps structure specification. This operation set includes file operations (open, read, write, lseek, pread, pwrite, close, fstat, fcntl, ioctl, fsync, etc.), directory operations (stat, link, unlink, rename, opendir, readdir, readdir_r, telldir, seekdir, closedir, mkdir, rmdir, access, truncate, ftruncate, utime, etc.), and selection operations (start_select, socket_select, stop_socket_select, stop_socket_select_isr, get_socket_select_semaphore, end_select, etc.). Each operation must be implemented in two versions: one with context (with the _p suffix) and one without context, to adapt to different scenarios (such as write_p and write in HzptVfsFsOps, stat_p and stat in HzptVfsFsOps, etc.).

[0040] 202: The file system to be registered needs to prepare a context pointer (ctx) to store its own private data (such as the file system information of fatfs, device handles, mount parameters, etc.); if no context is needed, it can be set to NULL.

[0041] 203: The file system to be registered must provide the registration path (path) and path length (path_len). The path must meet the following specifications: If the path length (path_len) is not HzptVfs_FILE_NAME_LEN_IGNORED (the length of filenames that can be ignored in HzptVfs, defined in HzptVfs_config.h, with a value of 0), then the length must not exceed HzptVfs_MAX_FILE_NAME_LEN (the maximum file length defined in fsfs, defined in HzptVfs_config.h, with a value of 64). When the path length is not less than 2, it cannot start with ' / ' and cannot end with ' / ' (refer to the path validity check in the HzptVfsRegisterStatic function). If no path needs to be specified, path can be set to NULL and path_len to HzptVfs_FILE_NAME_LEN_IGNORED.

[0042] 204: The file system to be registered needs to have its file system flags (fsflags) set, including: HzptVfs_FLAGS_READONLY: Indicates that the file system is in read-only mode. After registration, it can be dynamically set through the HzptVfsSetReadOnlyFlag function (defined in HzptVfs_ops.c); HzptVfs_FLAGS_CONTEXT_PTR: Indicates that the file system needs to use a context pointer (ctx), and VFS will preferentially call operation functions with the _p suffix; HzptVfs_FLAGS_STATIC: Indicates that the file system is of static type, and no copy operation set is required during registration (the passed-in ops pointer is directly reused); the flag bit is used by VFS to identify the characteristics of the file system, and then adapt to the corresponding operation call logic (such as the judgment of the flag bit in functions such as HzptVfsOpen, HzptVfsRead, etc.).

[0043] 205: The file system to be registered must ensure that the provided operation set matches its own characteristics, for example: If HzptVfs_FLAGS_READONLY is set, it must be ensured that write operations (write, pwrite, etc.) return a reasonable error when they are called, or that the VFS layer (such as the HzptVfsWrite function) directly intercepts the write operation and returns an EROFS error. If a certain type of operation (such as fsync) is not supported, the corresponding operation pointer must be set to NULL. VFS will return an ENOSYS error when the function is called (such as the check logic in the HzptVfsFsync function).

[0044] 206: For operations that rely on path resolution (such as open, stat, etc.), the file system to be registered must support the path conversion mechanism of the VFS layer, that is, be able to handle the internal path (path_within_vfs) after conversion by the HzptVfsTranslatePath function. This path is a relative path after removing the registration path prefix (such as the path processing flow in functions such as HzptVfsOpen, HzptVfsStat, etc.).

[0045] The implementation of the HzptVfsTranslatePath function is based on the matching relationship between the registered path prefix and the path passed in from the upper layer. The specific steps are as follows: The function receives two parameters: a file system node (fs_node, containing the registration path and length of the file system, as described in steps 304-305) and a complete path passed from the upper layer (path, such as the input path for operations like open and stat). First, it verifies through a FASSERT assertion that the prefix of the path passed from the upper layer matches the registration path of the file system node (fs_node->path), ensuring the path belongs to that file system (depending on the validity of the registration path in step 203 and the path prefix matching logic in step 307). If the length of the path passed from the upper layer (path) is equal to the length of the registration path (fs_node->path_len), it indicates that the path points to the registered root directory of the file system, and " / " is returned as the internal relative path (path_within_vfs). If the length of the path passed from the upper layer (path) is greater than the length of the registration path (fs_node->path_len), then the path pointer is returned at an offset from the length of the registration path (path+fs_node->path_len), i.e., the remaining part after removing the registration path prefix is ​​used as the internal relative path (path_within_vfs).

[0046] The internal paths (path_within_vfs) that the file system to be registered needs to process meet the following characteristics: When the upper layer accesses the file system registration root directory, the internal path is " / "; When the upper layer accesses a sub-path under the registered path, the internal path is the sub-path part (e.g., if the registered path is "mnt / fat" and the upper layer path is "mnt / fat / file.txt", the internal path is " / file.txt"). The internal path format is compatible with the path specification of the file system to be registered (depending on the format constraints of the registered path in step 203).

[0047] (III) The registration execution phase of the file system to be registered. The core of this phase is to formally register the prepared file system resources into the VFS so that they can be recognized and managed by the system. The specific steps are as follows: 301: The file system to be registered initiates registration by calling the HzptVfsRegister function. This function first achieves multi-threaded synchronization through the VFS lock (vfs_lock) (by calling the F_KernelLock function to acquire the lock), and then checks whether the operation set (operation set 201-206, i.e., 201-206 in the file system resource preparation stage) is NULL. If it is NULL, it returns an invalid parameter error (HzptVfs_ERR_INVALID_PARAM). The F_KernelLock function is the process lock function.

[0048] 302: The HzptVfsRegister function determines whether a file system is static based on the file system flags to be registered (equivalent to fsflags in 204): If HzptVfs_FLAGS_STATIC is included, then the HzptVfsRegisterStatic function is called directly; Otherwise, the operation set (ops) is copied to the VFS-managed memory pool (ops_mem_pool) using the HzptVfsOpsCopy function. During the copying process, the function pointers for the file operation set (fs_ops), directory operation set (dir_ops), and selection operation set (select_ops) with and without _p need to be processed separately. If the copying fails (e.g., due to insufficient memory pool space), an invalid parameter error (HzptVfs_ERR_INVALID_PARAM) is returned, and then the HzptVfsRegisterStatic function is called.

[0049] 303: The HzptVfsRegisterStatic function traverses the file system node table (vfs_fs_table), whose maximum capacity is limited by HzptVfs_MAX_NODE_NUM (defined in HzptVfs_config.h, with a value of 100), searching for unused nodes (fs_node->used_flg==0); if no usable node is found after the traversal is complete, it returns a not found error (HzptVfs_ERR_NOT_FOUND).

[0050] 304: After finding an available node, the HzptVfsRegisterStatic function performs the following node initialization operations: Set the node usage flag (fs_node->used_flg=1); If the path length (path_len) provided in step 203 is not HzptVfs_FILE_NAME_LEN_IGNORED, then copy the path (path) to the node path buffer (fs_node->path) and record the path length (fs_node->path_len=path_len). If no path needs to be specified, set fs_node->path to NULL and fs_node->path_len = HzptVfs_FILE_NAME_LEN_IGNORED.

[0051] 305: The HzptVfsRegisterStatic function populates the node's core information: The operation set pointer (fs_node->ops) points to the operation set processed in step 302 (the original pointer in static mode and the pointer copied from the memory pool in non-static mode); the context pointer (fs_node->ctx) is assigned the value of ctx provided in step 202; the flag bits (fs_node->fsflags) are assigned the value of fsflags provided in step 204; and the node index (fs_node->fs_index) is set to the array index of the current node in vfs_fs_table.

[0052] 306: If the registration function is passed an output parameter (id), the current node index (fs_index) is assigned to id as the unique identifier of the file system in the VFS; then the VFS lock is released (by calling the F_KernelUnlock function), and the registration success flag (HzptVfs_SUCCESS) is returned.

[0053] 307: After successful registration, VFS will bring the file system under unified management. When the upper layer calls POSIX interfaces (such as open, read, etc.): VFS layer functions (such as HzptVfsOpen) traverse the vfs_fs_table to find matching file system nodes (based on path prefix matching); The operation function to be called is selected based on the node flags (fsflags) with or without _p (e.g., if the HzptVfs_FLAGS_CONTEXT_PTR flag is present, open_p is called and the ctx parameter is passed in). The operation results are uniformly encapsulated by the VFS layer and returned to the upper layer, achieving transparent adaptation to different file systems.

[0054] 308: If an error occurs during the registration process (such as invalid parameters in step 301 or insufficient nodes in step 303), the HzptVfsRegister function will release the acquired VFS lock and return the corresponding error code to ensure VFS state consistency.

[0055] (iv) The VFS integration mechanism for different file systems is implemented in this stage. The core goal of this stage is to build a transparent, unified, and scalable abstraction layer, enabling upper-layer applications to seamlessly access various heterogeneous underlying file systems through the standard POSIX interface. The specific steps are as follows: 401: VFS integrates operation entry points through a unified POSIX standard interface layer. The interface layer includes file operations (HzptVfsOpen, HzptVfsRead, HzptVfsWrite, etc.), directory operations (HzptVfsOpendir, HzptVfsReaddir, HzptVfsMkdir, etc.), and attribute operations (HzptVfsStat, HzptVfsFstat, etc.). All interface functions encapsulate the differences of the underlying file system. Upper-layer applications can access any registered file system by calling these interfaces without needing to concern themselves with the specific implementation (refer to the definitions of each interface function in HzptVfs_posix.c).

[0056] 402: VFS implements the logical mapping of physical storage through the file system node table (vfs_fs_table). Each node (HzptVfsNode) in the table corresponds to a registered file system (as described in step 305). The node information includes operation set, context, path prefix, etc. When the upper layer initiates path-related operations, VFS calls the HzptVfsGetNodeByLongerPath function to locate the corresponding node through the longest path prefix matching algorithm (refer to the implementation of the HzptVfsGetNodeByLongerPath function in HzptVfs_ops.c), thereby achieving logical isolation and unified access for different file systems.

[0057] 403: VFS implements dynamic routing of function calls through an operation set adaptation layer. For each interface function (such as HzptVfsRead), it determines whether context is needed based on the file system node's flags (fsflags). If HzptVfs_FLAGS_CONTEXT_PTR is set (step 204), then the operation function with context (such as read_p) is called and the ctx parameter of the node is passed in (step 202). Otherwise, the operation function without context (such as read) is called without passing ctx; this mechanism ensures that operation functions of different file systems can be called correctly (refer to the operation function selection logic in functions such as HzptVfsRead and HzptVfsWrite).

[0058] 404: VFS achieves path consistency across file systems through a path conversion mechanism. For path-related operations (such as HzptVfsOpen and HzptVfsStat), after locating the file system node, the HzptVfsTranslatePath function in 206 is called to convert the absolute path passed from the upper layer into a relative path within the file system (removing the path prefix registered by the node), so that different file systems only need to process the relative paths within their own jurisdiction.

[0059] (V) The VFS unified management mechanism implementation stage. The core objective of this stage is to build a secure, stable, and efficient management framework to monitor and coordinate all registered file systems and their resources throughout their entire lifecycle. Its unified management mechanism is mainly achieved through the following key aspects: 501: VFS uses a file descriptor table (vfs_fd_table) to globally manage opened resources. When the file system's open operation is successful (as described in step 307), VFS calls the HzptVfsRegisterWithFd function to allocate a globally unique file descriptor for the file, recording the corresponding file system node index (fs_index) and the file ID (fd_id) within the file system. When closing a file, the descriptor is released using the HzptVfsFdUnregister function.

[0060] 502: VFS manages the lifecycle of operation sets through an operation memory pool (ops_mem_pool). For non-static file systems (where HzptVfs_FLAGS_STATIC is not set), the operation set is copied to the memory pool during registration using the HzptVfsOpsCopy function (in step 302), and the operation set resources (including structures for file operations, directory operations, and selection operations) in the memory pool are released during unloading (by calling the HzptVfsUnregister function). Static file systems directly reuse the passed-in operation set pointers without occupying memory pool resources (refer to the memory management logic of HzptVfsOpsCopy and HzptVfsUnregister in HzptVfs_ops.c).

[0061] 503: VFS manages the file system state dynamically by adjusting flags. It supports modifying the read-only state of the file system (HzptVfs_FLAGS_READONLY) using the HzptVfsSetReadOnlyFlag and HzptVfsClearReadOnlyFlag functions. When modifying, it traverses the file system node table to find the corresponding node and updates the flag. When performing a write operation (such as HzptVfsWrite), VFS checks the flag. If it is read-only, it returns an EROFS error (refer to the implementation of HzptVfsSetReadOnlyFlag in HzptVfs_ops.c and the flag check in HzptVfsWrite).

[0062] 504: VFS implements cross-file system error handling through a unified error code mapping. All interface functions convert errors of the underlying file system into standard POSIX error codes (such as ENOSYS indicating that the operation is not supported, and EROFS indicating a read-only file system), and set error information through the __errno_r function to ensure that upper-layer applications can handle errors of different file systems in a unified way (refer to the error code setting logic in functions such as HzptVfsRead and HzptVfsStat).

[0063] 505: VFS achieves dynamic removal of the file system through a node unloading mechanism. When the HzptVfsUnregister function is called, the corresponding file system node is found according to the path. If it is a non-static node, the operation set resources in the memory pool are released (step 502), and then the node's usage flag (used_flg=0) is cleared. If the node is unloaded through the HzptVfsUnRegisterUseId function, the node ID is directly located and the same operation is performed to ensure that the node no longer participates in operation routing after removal (refer to the implementation of HzptVfsUnregister and HzptVfsUnRegisterUseId in HzptVfs_ops.c).

[0064] 506: VFS ensures management security through a multi-threaded synchronization mechanism. In operations such as file descriptor allocation / release (step 501) and node registration / uninstallation (steps 301 and 505), critical section protection is implemented through VFS lock (vfs_lock, step 102) to avoid inconsistencies in node table or descriptor table data caused by multi-threaded concurrent operations (refer to the locking logic of HzptVfsRegisterWithFd in HzptVfs.c).

[0065] To efficiently and uniformly integrate different types of file systems into the Virtual File System (VFS) and support dynamic mounting and management of multiple storage media, this invention proposes a complete VFS adaptation interface method. This method significantly reduces the complexity of file system adaptation and the porting costs for developers through layered design, unified data structures, and standardized operation sets. The following sections systematically describe the specific implementation path for adapting a file system to VFS from three aspects: core data structure design, interface adaptation mechanism, and multi-media coexistence support. Figure 3 As shown.

[0066] Phase 1: File System Adaptation Data Structure Design Phase. The core objective of this phase is to build a unified, abstract, and efficient data model, providing a solid data foundation for the VFS framework to integrate diverse underlying file systems. This phase, through carefully designed key data structures and global management mechanisms, achieves standardized abstraction and centralized control over heterogeneous file system instances and their resources. The specific steps are as follows: 601: To achieve unified access across multiple file systems, the core data structure of the VFS layer is first designed (as described in step 305). In step 601, the VFS node structure HzptVfsNode is defined to abstract and manage a mounted file system instance. This structure contains the following fields: the fsflags variable is defined to identify file system attributes (such as whether it is statically registered, whether it supports context pointers, whether it is read-only, etc.), path stores the mount path of the file system, path_len records the path length, ops points to the operation set structure corresponding to the file system, ctx is the file system private context pointer, fs_index identifies the index position of the node in the global node table, and used_flg marks whether the node has been occupied.

[0067] 602: Based on the VFS node structure HzptVfsNode, step 602 further designs a file descriptor management structure HzptVfsFdNode to uniformly manage file descriptors in different file systems. This structure includes a used flag indicating whether the descriptor is used, fs_index pointing to the corresponding VFS node to determine the file system it belongs to, and fd_id recording the local descriptor number in the specific file system, thereby realizing the mapping and management of file descriptors between the VFS layer and the specific file system.

[0068] 603: To standardize the operation interface of different file systems in step 201, step 603 uses HzptVfsFsOps mentioned in step 201, which includes a series of standard file operation function pointers (such as open_p, write_p, read_p, etc.) and a pointer dir (of type HzptVfsDirOps) to a set of directory operations. This structure uses the HzptVfs_FLAGS_CONTEXT_PTR flag in the fsflags field mentioned in 601 to specify whether certain operations require passing the ctx context parameter, thus distinguishing the implementation differences between different file systems.

[0069] 604: Step 604 defines the directory operation set structure HzptVfsDirOps mentioned in 603, which contains function pointers (such as stat_p, mkdir_p, rename_p, etc.) for operating on directory and file attributes, and is used to unify the behavior interface of different file systems at the directory and file metadata operation level.

[0070] 605: To effectively manage file system instances and file descriptors in the system, step 605 designs two global tables: vfs_fs_table (type HzptVfsNode[HzptVfs_MAX_NODE_NUM]) mentioned in file system node table 303 and vfs_fd_table (type HzptVfsFdNode[HzptVfs_MAX_FD_NUM]) mentioned in file descriptor table 102. Access to these tables requires mutual exclusion through a global lock vfs_lock to ensure safe operation in a multi-threaded environment.

[0071] 606: To improve the memory allocation efficiency of the operation set structure, a memory pool `ops_mem_pool` will be created in step 101 of the `HzptVfsOpsInit` function during system initialization. This pool is used to dynamically allocate `HzptVfsFsOps` and `HzptVfsDirOps` structures. This mechanism avoids the performance overhead caused by frequent memory allocation and enhances the overall stability of the system.

[0072] Phase Two: File System Operation Set Interface Adaptation Phase. The core objective of this phase is to build a bridge connecting the concrete file system and the abstract VFS layer. This is achieved by implementing standardized operation interfaces and mapping the native functionality of the underlying file system to the unified VFS model, ultimately completing the registration and lifecycle management of file system instances. The steps can be summarized as follows: 701: After completing the VFS core data structure design, the first step is to implement the operation interface for specific file systems. Step 701, based on the HzptVfsFsOps structure defined in 601, implements the corresponding file operation functions using FATFS as an example. These mainly include: HzptVfsFatfsOpen (open file), HzptVfsFatfsWrite (write file), and HzptVfsFatfsRead (read file). Internally, these functions need to call the native FATFS API and convert their return codes to the standard errno error code using the HzptVfsFatfsReturnToErrno function to ensure the consistency of error handling at the VFS layer.

[0073] 702: Building upon this, step 702 implements the directory operation functions required by FATFS based on the HzptVfsDirOps structure defined in 604, including: HzptVfsFatfsDirStat (get file status), HzptVfsFatfsDirMkdir (create directory), HzptVfsFatfsDirUnlink (delete file), etc. Each function must first process the path prefix through HzptVfsFatfsAppendDrive to ensure that the path passed to FATFS correctly contains the driver identifier, thus achieving a complete mapping of the physical path.

[0074] 703: Next, in step 703, two static operation set structures are defined and initialized in the HzptVfs_fatfs.c file: vfs_fatfs_fs_ops (of type HzptVfsFsOps) and vfs_fatfs_dir_ops (of type HzptVfsDirOps). Their member function pointers are set to the FATFS adaptation functions implemented in 701 and 702, respectively. The flag HzptVfs_FLAGS_STATIC | HzptVfs_FLAGS_CONTEXT_PTR is set through the fsflags field mentioned in 601, indicating that the operation set is statically implemented and that related operations require passing a context pointer.

[0075] 704: Step 704 implements the core registration function HzptVfsFatfsRegister. This function internally allocates the necessary resources for the FATFS instance (such as the file object array file[] and the usage flag array file_flags[]), and then calls the VFS general registration interface HzptVfsRegister to mount the initialized vfs_fatfs_fs_ops operation set to the VFS. At the same time, it records key information such as the driver path and mount point into the dedicated HzptVfsFatfs structure, thus completing the registration and mounting of the file system instance.

[0076] 705: Finally, step 705 implements the corresponding unregister function HzptVfsFatfsUnRegister. This function unregisters and removes the specified node from the VFS by calling the HzptVfsUnregister interface, while ensuring the safe release of allocated resources such as the file_flags array, achieving complete resource cleanup and preventing memory leaks.

[0077] Phase Three: Device Layer and VFS Mounting Integration. The core objective of this phase is to establish a complete path from physical devices to the application layer. This is achieved by deeply integrating block device drivers, file system logic, and the VFS abstraction layer, ultimately enabling dynamic and unified management of storage devices. The specific steps are as follows: 801: First, implement the device mounting function HzptVfsFatfsDevMount in HzptVfs_fatfs_dev.c. This function is the entry point for the device driver. Its core task is to call the corresponding underlying disk I / O registration function (e.g., ff_diskio_register_fsdif_tf) based on the specified device type (such as SD card, eMMC, or RAM disk) to complete the initialization of the specific block device and provide the underlying read / write interface for FATFS.

[0078] 802: After successfully initializing the disk I / O layer (801), the file system is mounted using the FATFS standard API `f_mount`. In this step, the function needs to check if a valid FATFS file system already exists on the target device. If the device is found to be unformatted or the caller requests forced formatting, the `f_mkfs` function is called to perform the formatting operation. The formatting parameter `MKFS_PARM` is used for critical configurations, such as cluster size, sector alignment, and file system type (FAT16 / FAT32 / exFAT, etc.), to ensure that a file system that meets expectations is created.

[0079] 803: After the file system is successfully mounted, the HzptVfsFatfsRegister function implemented in step 704 is called. This call formally registers the FATFS operation set with the VFS framework, thereby establishing a complete call chain from the application layer VFS interface to the middle layer FATFS, and then to the underlying device driver, achieving seamless integration of the three layers.

[0080] 804: Finally, implement the symmetric device unmount function HzptVfsFatfsDevUnmount. This function is responsible for the complete cleanup process: first, it calls f_mount to unmount the FATFS logical volume, then it calls ff_diskio_unregister to unregister the underlying disk driver, and finally it calls the HzptVfsFatfsUnRegister function to clean up the registration information and related resources in the VFS, ensuring that all levels can be correctly unmounted without resource leaks.

[0081] Phase Four: VFS Unified Interface Call Phase. This phase is crucial for the ultimate realization of the VFS framework's value. Its core objective is to provide upper-layer applications with a completely transparent, unified, and POSIX-compliant file access interface, and intelligently route and adapt these common calls to different underlying file systems. The specific steps are as follows: 901: Based on the global file system node table vfs_fs_table maintained in step 605, implement POSIX standard interfaces (such as HzptVfsOpen, HzptVfsWrite, etc.) in HzptVfs_posix.c. These interfaces first call the path resolution function HzptVfsGetNodeByLongerPath to find the longest matching mounted file system node (i.e., HzptVfsNode structure instance) in the node table according to the file path; then, HzptVfsTranslatePath is used to convert the application layer path into the internal path format required by the file system, preparing for subsequent operations.

[0082] 902: Based on obtaining the target VFS node (fs_node) and its transformed path in 901, determine whether to pass context parameters when calling its operation set functions, depending on whether the node's fsflags field (as defined in step 601) contains the HzptVfs_FLAGS_CONTEXT_PTR flag. For example, during file write operations: If the flag is already set, then call: fs_node->ops->write_p(fs_node->ctx,fd_node->fd_id,data,size); If not set, then call: fs_node->ops->write_p(fd_node->fd_id,data,size). This mechanism is a unified application of the operation described in step 603, ensuring flexibility in operation interface adaptation.

[0083] 903: When a file or directory is successfully opened, the returned VFS file descriptor is registered in the global file descriptor table vfs_fd_table (managed as in step 605) using the function HzptVfsRegisterWithFd, establishing a mapping relationship between VFS layer file descriptors and specific file system local descriptors (this mapping relationship is maintained by the HzptVfsFdNode structure defined in step 602). When HzptVfsClose is called, the mapping is released and descriptor resources are released using HzptVfsFdUnregister, achieving unified management of file handles.

[0084] 904: For directory operation interfaces (such as HzptVfsOpendir, HzptVfsMkdir, etc.), the specific file system implementation functions are called through function pointers under fs_node->ops->dir (whose type is the HzptVfsDirOps operation set defined in step 604). Before calling, the file system attributes (such as whether it is read-only) and whether it supports the corresponding operation must be verified to ensure the legality and security of the call, thereby fully realizing the unified access for directory and file metadata operations.

[0085] Adapting a specific file system (taking FATFS as an example) to the Virtual File System (VFS) framework is accomplished through a clear, layered, and standardized four-stage process. Its core lies in shielding the underlying differences between different file systems and storage media through unified data abstraction and interface specifications.

[0086] Explanation of the structures mentioned above: 1. HzptVfsNode (virtual file system node structure); This structure represents a file system instance mounted to VFS and is the basic unit of VFS management.

[0087] Functions and uses: Identification Management: fsflags: Flags that indicate file system characteristics (default behavior, whether a context pointer is required, whether it is read-only). fs_index: A unique index in the global list of HzptVfsNodes; used_flg: The node's usage status flag (1 = used, 0 = unused); Path management: path[]: The absolute path of the file system mount point; path_len: Path length, to avoid frequent calls to strlen; Operation interface: ops: Pointer to the HzptVfsFsOps structure, which contains all the operation functions for this file system; ctx: Context pointer, pointing to private data in the underlying file system.

[0088] Processing logic: When an application accesses a path, VFS finds the corresponding HzptVfsNode by comparing the path field, and then calls the specific file operation function through its ops.

[0089] 2.HzptVfsFsOps (file system operation interface structure); This structure defines a standard interface for file-level operations and uses a union design to support function versions with and without context pointers.

[0090] Functions and uses: File I / O operations: write / write_p: Writes data to an already opened file; read / read_p: Read data from an open file; pwrite / pwrite_p: Write data at the specified offset (without affecting the file pointer); pread / pread_p: Reads data at the specified offset (without affecting the file pointer); lseek / lseek_p: Move the file read / write position pointer; File lifecycle management: open / open_p: Opens a file and establishes an association between the file descriptor and the underlying file; close / close_p: Close the file and release related resources; fsync / fsync_p: Synchronizes file cache data to physical storage; File metadata and control: fstat / fstat_p: Get attribute information (size, permissions, etc.) of open files; fcntl / fcntl_p: File control operations (setting non-blocking, getting status, etc.); ioctl / ioctl_p: Device-specific control (file system-specific operations); Directory and selection operations: dir: points to HzptVfsDirOps, providing directory-level operations; select: Points to HzptVfsSelectOps, which provides multiplexing support (not defined).

[0091] Design features: Context pointer support: Each operation has two versions, with access to file system private data via the ctx parameter; Unified interface: Different file systems (FAT32, EXT4, NFS, etc.) can access VFS by implementing the same interface.

[0092] 3.HzptVfsFdNode (file descriptor node structure); This structure represents a management unit for an open file descriptor in the VFS.

[0093] Functions and uses: State Management: used: Bit field, indicating whether the file descriptor is valid (1=valid, 0=invalid / closed); Relationship: fs_index: points to the corresponding HzptVfsNode, which determines the file system to which the file belongs; fd_id: File descriptor ID, uniquely identifies an open file within a process; Processing logic: When the application successfully calls open(), the VFS allocates a HzptVfsFdNode to record the file system index and fd_id. Subsequent read / write operations use the fd_id to find the corresponding HzptVfsFdNode, and then use the fs_index to find the specific file system operation function.

[0094] 4.HzptVfsDirOps (directory operation interface structure); This structure specifically defines the operation interface related to directories and paths, separating it from file I / O operations, which conforms to the design philosophy of the UNIX file system.

[0095] Functions and uses: File metadata operations: stat / stat_p: Retrieves metadata for files / directories via paths; access / access_p: Checks file access permissions; utime / utime_p: Modify file access / modification time; Directory operations: opendir / opendir_p: Opens a directory stream; readdir / readdir_p: Read directory entries (not thread-safe); readdir_r / readdir_r_p: Read directory entries (reentrant, thread-safe); telldir / telldir_p: Get the current position of the directory stream; seekdir / seekdir_p: Sets the directory stream location; closedir / closedir_p: Close the directory stream; File / directory management: mkdir / mkdir_p: Create a new directory; rmdir / rmdir_p: Deletes an empty directory; link / link_p: Creates a hard link; unlink / unlink_p: Remove file links (file deletion); rename / rename_p: rename / move files / directories; File size control: truncate / truncate_p: truncates a file by its path; ftruncate / ftruncate_p: Truncate a file by its file descriptor.

[0096] This invention defines a streamlined, unified file operation interface (such as open, read, write, and close) that is compatible with the POSIX standard. This interface serves as the sole entry point for upper-layer applications to access any underlying file system, completely shielding the implementation details of heterogeneous file systems such as FatFS, YAFFS, SPIFFS, and NFS, thereby solving the software reuse problem caused by ecosystem fragmentation.

[0097] This invention designs a standard Adapter Layer Interface. For any new file system or peripheral, developers only need to implement a set of simple callback functions (such as mount, unmount, file_operations) based on this interface to complete the integration. This method greatly simplifies the process of connecting different storage devices, network resources, and even peripherals (such as sensors) to the system as "files," significantly reducing adaptation costs and complexity.

[0098] This invention aims to efficiently integrate block-based (e.g., FatFS) and byte-oriented (e.g., SPIFFS) file systems by abstracting and implementing a Common Block Device Layer and a buffer management mechanism in the adaptation layer. For byte-based file systems, this layer simulates the required block operations; for block device file systems, it directly calls their native interfaces. Through this step, seamless unified management of the two types of file systems at the architectural and access levels is achieved.

[0099] Explanations of some terms are shown in Table 1.

[0100] Table 1 The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for implementing a virtual file system in an embedded bare-metal environment, characterized in that, Includes the following steps: Initialize the global management resources of the Virtual File System (VFS), which include a file system node table for managing file system instances; Obtain the registration resources of the underlying file system instance to be accessed; Based on the registration resources, the underlying file system instance to be accessed is registered to the file system node table, generating the corresponding VFS node; wherein, the registration resources include: a standardized operation set conforming to the HzptVfsFsOps structure and the HzptVfsDirOps structure definition, the mount path of the file system, the file system flag bit and the private context pointer. In response to a file access request from the application layer, the corresponding target VFS node is matched from the file system node table based on the target path in the file access request. By using the standardized set of operations associated with the target VFS node, the file access request is forwarded to the target underlying file system for execution, thereby enabling access to heterogeneous underlying file systems through a unified interface.

2. The method for implementing a virtual file system in an embedded bare-metal environment according to claim 1, characterized in that, The HzptVfsInit function is called to initialize the global management resources of the Virtual File System (VFS), including: Create and initialize the file system node table; in the HzptVfsInit function, call the HzptVfsOpsInit function to create an operation memory pool to manage the memory allocation of the HzptVfsFsOps and HzptVfsDirOps structures; initialize the VFS lock for multi-threaded synchronization; perform a memory zeroing operation on the file descriptor table to initialize all file descriptors to an unused state.

3. The method for implementing a virtual file system in an embedded bare-metal environment according to claim 1, characterized in that, Obtain the standardized set of operations that conform to the definitions of the HzptVfsFsOps and HzptVfsDirOps structures, including: The HzptVfsFsOps structure encapsulates file-level operations, and its members are pointers to file-level operation functions. Each file-level operation provides a function version with a context pointer parameter and a function version without a context pointer parameter through a union. The HzptVfsDirOps structure encapsulates directory-level operations, and its members are pointers to directory-level operation functions. Each directory-level operation provides a function version with a context pointer parameter and a function version without a context pointer parameter through a union.

4. The method for implementing a virtual file system in an embedded bare-metal environment according to claim 3, characterized in that, The HzptVfsFsOps structure also includes a select pointer, which points to the HzptVfsSelectOps structure. The HzptVfsSelectOps structure encapsulates selection operations, and its members are pointers to selection operation functions used to support multiplexing operations.

5. The method for implementing a virtual file system in an embedded bare-metal environment according to claim 1, characterized in that, Based on the registered resources, the underlying file system instance to be connected is registered to the file system node table, generating the corresponding VFS node, including: Call the HzptVfsRegister function, passing in a pointer to the standardized operation set, the private context pointer, the mount path, and the file system flags; Based on whether the file system flags contain the HzptVfs_FLAGS_STATIC flag, determine whether to copy the standardized operation set to the operation memory pool using the HzptVfsOpsCopy function; Traverse the file system node table to find unused entries with a usage status marker of 0; The mount path, the file system flag, the processed operation set pointer, and the private context pointer are filled into the found entry, and the usage status flag is set to 1. At the same time, the index of the corresponding entry is recorded, and the corresponding VFS node is generated.

6. The method for implementing a virtual file system in an embedded bare-metal environment according to claim 1, characterized in that, Matching the corresponding target VFS node from the file system node table based on the target path in the file access request, including: Traverse the file system node table to obtain each VFS node; Check the usage status flag of each VFS node and filter out all nodes marked as used as candidate nodes; For each candidate node, the mount path stored in its path field is used as a prefix and compared with the target path in the file access request to determine whether the target path is prefixed with the corresponding mount path. From all candidate nodes that meet the prefix matching condition, select the node with the longest mount path and determine it as the target VFS node.

7. The method for implementing a virtual file system in an embedded bare-metal environment according to claim 6, characterized in that, File access requests are forwarded to the target underlying file system for execution via the standardized set of operations associated with the target VFS node, including: The HzptVfsTranslatePath function is called to convert the target path into a relative path within the underlying file system based on the path field and path length field of the target VFS node. Then, based on the file system flag of the target VFS node, the corresponding function in the standardized operation set is called accordingly.

8. The method for implementing a virtual file system in an embedded bare-metal environment according to claim 7, characterized in that, Based on whether the target VFS node's file system flag field contains the HzptVfs_FLAGS_CONTEXT_PTR flag, determine whether a context pointer needs to be passed. If the HzptVfs_FLAGS_CONTEXT_PTR flag is present, call the corresponding function version in the HzptVfsFsOps or HzptVfsDirOps structure with a context pointer parameter, and pass the private context pointer. If the HzptVfs_FLAGS_CONTEXT_PTR flag is not present, call the corresponding function version without a context pointer parameter.

9. The method for implementing a virtual file system in an embedded bare-metal environment according to claim 2, characterized in that, Once the file is successfully opened using the standardized operation set and the file identifier returned by the underlying file system is obtained, the HzptVfsRegisterWithFd function is called. The HzptVfsRegisterWithFd function allocates a file descriptor node structure in the file descriptor table; sets the index field of the allocated file descriptor node structure to the index of the file system node structure corresponding to the opened file; and records the file identifier returned by the underlying file system in the file identifier field of the allocated file descriptor node structure. The file descriptors generated based on the allocated file descriptor node structure and valid at the VFS layer are returned to the application layer.

10. A virtual file system in an embedded bare-metal environment, used to execute the implementation method of claim 1, characterized in that, include: The global management resource initialization module is used to initialize the global management resources of the virtual file system (VFS), wherein the global management resources include a file system node table for managing file system instances; The registration resource processing and node management module is used to obtain the registration resources of the underlying file system instance to be connected, and register the underlying file system instance to the file system node table based on the registration resources to generate the corresponding VFS node; wherein, the registration resources include: a standardized operation set conforming to the HzptVfsFsOps structure and the HzptVfsDirOps structure definition, the mount path of the file system, the file system flag bit and the private context pointer; The request routing and execution module is used to respond to file access requests from the application layer, match the corresponding target VFS node from the file system node table according to the target path in the file access request, and forward the file access request to the target underlying file system for execution through the standardized operation set associated with the target VFS node.

Images