Access device, method, medium and device for a device

Abstract

The present disclosure provides an access device, method, medium and device of a device, in the case of obtaining, in a first operating system, a first operation request initiated by an application program for a target device file, determining a second operation request for accessing a first file system based on file identification information of the target device file in the first operation request, determining a target drive callback function identifier corresponding to the file identification information of the target device file among a plurality of drive callback function identifiers pre-registered by a drive program corresponding to the target device based on the second operation request, and executing an access operation on the target device by calling a target drive callback function corresponding to the target drive callback function identifier in the drive program, thereby realizing the function of the first file system supported by the second operating system in the first operating system, so as to reuse the drive program developed for the second operating system, reduce the development cost of the drive program, and improve the universality of the drive program.

Description

Technical Field

[0001] This disclosure relates to operating system technology, and in particular to a device access device, method, medium, and apparatus. Background Technology

[0002] In operating systems, devices are typically accessed through their corresponding drivers. These devices include, for example, cameras, radars, sound cards, graphics cards, network cards, and storage devices. Different operating systems require separate drivers for the same device, resulting in high development costs and low driver compatibility. Summary of the Invention

[0003] Embodiments of this disclosure provide a device access apparatus, method, medium, and device to support system file system (sysfs) functionality in a first operating system, thereby enabling the use of a driver designed for a second operating system to access the device in the first operating system, avoiding the need to redesign the driver for the first operating system, reducing development costs, and improving the versatility of the driver.

[0004] A first aspect of this disclosure provides a device access apparatus, comprising: in a first operating system, acquiring a first operation request initiated by an application for a target device file; determining a second operation request for accessing a first file system based on file identification information of the target device file in the first operation request, wherein the first file system is a file system of a preset type supported by a second operating system; the first file system includes multiple device files corresponding to multiple file identification information; based on the second operation request, determining a target driver callback function identifier corresponding to the file identification information of the target device file from multiple driver callback function identifiers pre-registered by a driver corresponding to the target device; and performing an access operation on the target device by calling the target driver callback function in the driver corresponding to the target driver callback function identifier.

[0005] A second aspect of this disclosure provides a device access method, comprising: in a first operating system, obtaining a first operation request initiated by an application for a target device file; determining a second operation request for accessing a first file system based on file identification information of the target device file in the first operation request, wherein the first file system is a file system of a preset type supported by a second operating system; the first file system includes multiple device files corresponding to multiple file identification information respectively; based on the second operation request, determining a target driver callback function identifier corresponding to the file identification information of the target device file from multiple driver callback function identifiers pre-registered by a driver corresponding to the target device; and performing an access operation on the target device by calling the target driver callback function in the driver corresponding to the target driver callback function identifier.

[0006] A third aspect of this disclosure is to provide a computer-readable storage medium storing a computer program that is executed by a processor to perform the device access method described in any of the above embodiments of this disclosure.

[0007] A fourth aspect of this disclosure provides an electronic device, the electronic device comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory, the processor executing the executable instructions to implement the device access method described in any of the above embodiments of this disclosure.

[0008] A fifth aspect of this disclosure provides a computer program product that, when instructions in the computer program product are executed by a processor, performs a device access method provided in any of the above embodiments of this disclosure.

[0009] Based on the device access apparatus, method, medium, and device provided in the above embodiments of this disclosure, when a first operation request initiated by an application for a target device file is obtained in the first operating system, a second operation request for accessing the first file system is determined based on the file identification information of the target device file in the first operation request. Then, based on the second operation request, a target driver callback function identifier corresponding to the file identification information of the target device file is determined from among multiple driver callback function identifiers pre-registered by the driver corresponding to the target device. An access operation is performed on the target device by calling the target driver callback function corresponding to the target driver callback function identifier in the driver. Since the first file system is a preset type of file system supported by the second operating system, this disclosure converts the first operation request into a second operation request for accessing the first file system in the first operating system, enabling the first operating system to support the first file system. Therefore, in the first operating system, the driver can be triggered to access the device based on the application's operation on the device file. This driver can reuse drivers supported by the second operating system, avoiding the need to redevelop drivers for the first operating system, effectively reducing development costs and improving the versatility of the driver. Attached Figure Description

[0010] Figure 1 This is an exemplary application scenario of the access device for the device provided in this disclosure; Figure 2 This is a schematic diagram of the structure of an access device for a device provided in an exemplary embodiment of the present disclosure; Figure 3 This is a schematic diagram of the software architecture of an access device for a device provided in an exemplary embodiment of this disclosure; Figure 4 This is a schematic flowchart of a device access method provided in an exemplary embodiment of this disclosure; Figure 5 This is a flowchart illustrating a device access method provided in another exemplary embodiment of this disclosure; Figure 6 This is a flowchart illustrating a device access method provided in yet another exemplary embodiment of this disclosure; Figure 7 This is a schematic flowchart of a device access method provided in yet another exemplary embodiment of this disclosure; Figure 8 This is a flowchart illustrating a device access method provided in yet another exemplary embodiment of this disclosure; Figure 9 This is a schematic flowchart of a device access method provided in yet another exemplary embodiment of this disclosure; Figure 10 This is a structural diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0011] To explain this disclosure, exemplary embodiments of the disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the disclosure, and not all of them. It should be understood that the disclosure is not limited to exemplary embodiments.

[0012] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0013] This disclosure outlines In developing this disclosure, the inventors discovered that operating systems typically require device drivers to access devices, such as cameras, radars, sound cards, graphics cards, network cards, and storage devices. For the same device, separate drivers need to be designed for different operating systems, making it difficult to use device drivers across operating systems. For example, in some operating systems (referred to as the second operating system), device attribute information is typically provided to user space as device files through the System File System (sysfs), allowing user-space applications (APPs) to access the device by manipulating these device files and triggering driver calls. However, other operating systems (referred to as the first operating system) do not support sysfs, requiring redesigned drivers for the first operating system to access devices. Redesigning drivers increases costs and reduces versatility.

[0014] Exemplary Overview Figure 1 This is an exemplary application scenario of the access device for the equipment provided in this disclosure. For example... Figure 1 As shown, in the system-on-a-chip 10, application program 11 can access any device 13 by calling driver program 121 through the first operating system 12. Application program 11 can run in the runtime environment provided by the first operating system 12. The first operating system 12 is the software between application program 11 and hardware device 13, responsible for managing hardware resources and providing access interface for application program 11. Driver program 121 can be part of the first operating system 12, and driver program 121 is mainly used to control device 13. Driver program 121 can shield the hardware details of the device, so that upper-layer applications do not need to care about the specific hardware implementation. Specifically, application program 11 can initiate a first operation request to the first operating system 12 for a target device file, the target device file being a description of the target device (e.g., ...). Figure 1The first operating system 12 can determine a second operation request for accessing the first file system based on the file identifier information of the target device file in the first operation request. Then, based on the second operation request, it can determine the target driver callback function identifier corresponding to the file identifier information of the target device file from multiple driver callback function identifiers pre-registered by the driver corresponding to the target device. By calling the target driver callback function in the driver corresponding to the target driver callback function identifier, it can perform an access operation on the target device.

[0015] In this disclosure, since the first file system is a preset type of file system supported by the second operating system, this disclosure converts the first operation request into a second operation request for accessing the first file system in the first operating system, enabling the first operating system to support the first file system. Thus, in the first operating system, the application's operation on the first file system can trigger the invocation of the driver to access the device. Since the first file system is a virtual file system supported by the second operating system, the role of the first file system is to represent the association between the device and the driver through a target tree structure and symbolic links. This allows the application to trigger the invocation of the driver by accessing the device file in the first file system. The invoked driver can reuse the driver supported by the second operating system to access the device, thereby avoiding the need to redevelop the driver for the first operating system, effectively reducing development costs and improving the versatility of the driver.

[0016] Exemplary device Figure 2 This is a schematic diagram of the structure of an access device for a device provided in an exemplary embodiment of this disclosure. The access device for a device provided in the embodiments of this disclosure is, for example, but not limited to, an electronic device, a system-on-a-chip (SoC), or hardware applied to an electronic device or SoC. The electronic device includes, for example, but not limited to, an in-vehicle computing platform (or in-vehicle terminal), an embodied intelligent agent, a mobile phone, a tablet, a wearable device, etc. The SoC includes, for example, but not limited to, an intelligent driving SoC, an intelligent cockpit SoC, a cockpit-driver integrated SoC, etc., such as... Figure 2 As shown, the access device 20 of the device in this embodiment of the present disclosure may include: a processor 21, which is configured to: In the first operating system, a first operation request initiated by the application for the target device file is obtained; based on the file identification information of the target device file in the first operation request, a second operation request for accessing the first file system is determined, wherein the first file system is a file system of a preset type supported by the second operating system; the first file system includes multiple device files corresponding to multiple file identification information respectively; based on the second operation request, a target driver callback function identifier corresponding to the file identification information of the target device file is determined from multiple driver callback function identifiers pre-registered by the driver corresponding to the target device; and an access operation is performed on the target device by calling the target driver callback function in the driver corresponding to the target driver callback function identifier.

[0017] In this embodiment, the first file system is a memory-based virtual file system. The first file system is a preset type of file system supported by the second operating system, for example, the first file system is sysfs. The first operating system is a different operating system from the second operating system. Optionally, the second operating system is, for example, but not limited to, Linux, and the first operating system is, for example, but not limited to, QNX (QNX Neutrino Real-Time Operating System). The first operating system does not originally support the first file system. By adding the device access functionality of this disclosure to the first operating system, the first operating system can support the first file system. Applications can access devices by manipulating device files in the first file system.

[0018] In some alternative embodiments, the application can be any software that needs to access a device and runs within the runtime environment provided by the first operating system. The first file system exposes the file identification information of each device file to user space in the form of a device file directory, enabling user-space applications to initiate a first operation request for the device file based on its file identification information. The file identification information is the information that can locate the corresponding device file in the first file system. The file identification information includes, but is not limited to, the path information or filename of the device file in the first file system. Device files are a way for the first operating system to expose hardware devices and their attributes to user space in the form of files, mounted under the device file directory, providing an interface for applications to access hardware devices.

[0019] The first file system includes multiple pre-created device files (or device nodes). The target device file is the device file that the application needs to operate on among the multiple device files in the first file system. The application can initiate a first operation request based on the file identification information of the target device file. Optionally, the application can use the file identification information of the target device file as a request parameter to generate the first operation request, that is, the first operation request includes the file identification information of the target device file; or, the file identification information of the target device file can be transmitted along with the first operation request, that is, the first operation request carries the file identification information of the target device file. Optionally, the first operation request may also include an operation type. Operation types include, but are not limited to, read operations, write operations, open file operations, close file operations, etc.

[0020] When the first operating system receives a first operation request, it can determine a second operation request for accessing the first file system based on the file identification information of the target device file in the first operation request. The second operation request may include the file identification information of the target device file; however, the request format of the second operation request may differ from that of the first operation request. The request format of the second operation request is set based on the request format supported by the first file system to ensure that the second operation request is compatible with the first file system. The request format may include the format of the operation type and the format of the request parameters. For example, the first operation request is represented as `read` (parameter 1), and the second operation request is represented as `sysfs_read` (parameter 2). The format of the operation type in the second operation request is `sysfs_read`, and the format of the operation type in the first operation request is `read`. The format of the request parameter in the second operation request is `parameter 2`, and the format of the request parameter in the first operation request is `parameter 1`. The data format of parameter 2 may differ from that of parameter 1, but parameter 2 and parameter 1 can be different representations of the same file identification information. In other words, in order to support the first file system, the first operation request can be converted into a second operation request for accessing the first file system. In this way, for the first file system, it is equivalent to obtaining a second operation request from the application. Thus, just like the second operating system, the first operating system can trigger the call of the driver function through the access operation of the device file in the first file system, thereby realizing access to the device.

[0021] After determining the second operation request, based on the second operation request, the target driver callback function identifier corresponding to the file identifier information of the target device file can be determined from among multiple driver callback function identifiers pre-registered by the driver corresponding to the target device. The driver corresponding to the target device can reuse a driver designed for a second operating system. Optionally, when the driver starts, the driver can register the identifiers of its implemented multiple driver callback functions (i.e., driver callback function identifiers) and the file identifier information of the device file corresponding to each driver callback function with the first operating system. After determining the second operation request, the file identifier information of the target device file can be extracted from the second operation request. Based on the file identifier information of the target device file and the correspondence between the multiple driver callback function identifiers and the file identifier information, the target driver callback function identifier corresponding to the file identifier information of the target device file can be determined from among the multiple driver callback function identifiers. A driver callback function is a function in the driver used to access or control the device. Driver callback functions include, but are not limited to, driver read functions (driver_show) and driver write functions (driver_store). The driver read function is used to read the attribute values ​​inside the driver and output them to the application, while the driver write function is used to receive data written by the application and write it to the driver.

[0022] After identifying the target driver callback function identifier, the corresponding target driver callback function in the driver program can be invoked based on the identifier. Executing the target driver callback function enables access to the target device and yields the access result. Optionally, the access result can be returned to the application, for example, through the first operating system. The access result may be, but is not limited to, a read access result or a write access result. A read access result may include, for example, the device attribute value corresponding to the first operation request read from the driver program. A write access result may include, for example, a write success message indicating that data was written to the driver program. In other words, access to the target device can include reading and writing attribute values ​​of the target device in the driver program. Optionally, when the access operation is a write operation, the access to the target device may further include configuring the target device based on the written attribute values ​​in response to the completion of the target driver callback function execution. For example, the attribute values ​​can be written to the corresponding registers or memory-mapped areas in the target device to update the device configuration.

[0023] The device access apparatus provided in this embodiment of the present disclosure, when obtaining a first operation request initiated by an application for a target device file in a first operating system, determines a second operation request for accessing a first file system based on the file identification information of the target device file in the first operation request, and then, based on the second operation request, determines a target driver callback function identifier corresponding to the file identification information of the target device file from a plurality of driver callback function identifiers pre-registered by the driver corresponding to the target device, and performs an access operation on the target device by calling the target driver callback function in the driver corresponding to the target driver callback function identifier. Since the first file system is a preset type of file system supported by the second operating system, this disclosure converts the first operation request into a second operation request for accessing the first file system in the first operating system, enabling the first operating system to support the first file system. This allows the first operating system to trigger a driver call to access the device based on the application's operation on the device file in the first file system. Because the first file system is a virtual file system supported by the second operating system, its function is to represent the relationship between devices and drivers through a target tree structure and symbolic links. This allows user-space applications to access device files through the first file system and trigger a driver call. The called driver can reuse drivers supported by the second operating system, thus avoiding the need to redevelop drivers for the first operating system, effectively reducing development costs and improving the versatility of the drivers.

[0024] In some alternative embodiments, based on any of the above embodiments, the processor 21 is further configured to: Obtain the first callback function registration request initiated by the driver corresponding to the target device; based on the file identifier information to be registered and its corresponding driver callback function identifier in the first callback function registration request, perform the registration of the driver callback function identifier corresponding to the file identifier information, and create a device file directory corresponding to the file identifier information in the first file system.

[0025] The first callback function registration request is a request initiated by the driver corresponding to the target device to register driver callback functions with the first operating system. The first callback function registration request may include one or more driver callback function identifiers and their corresponding file identifier information. Upon receiving the first callback function registration request, the file identifier information and the corresponding driver callback function identifier can be extracted from the request. Based on the file identifier information and its corresponding driver callback function identifier, registration of the driver callback function identifier corresponding to the file identifier information is performed. Registration may include storing each file identifier information in relation to its corresponding driver callback function identifier, so that when the application initiates the first operation request to the target device file, the first operating system can locate the corresponding target driver callback function identifier based on the file identifier information of the target device file. During or after registration, a device file directory corresponding to each file identifier information can be created in the first file system. The first file system exposes information about the device and driver to user space in the form of a device file directory, organizing devices, drivers, and other objects in the form of files and directories, allowing user-space applications to easily view device information. Device information includes, but is not limited to, device status, attributes, and configuration information. The device file directory may be represented as, but is not limited to, / sys / sample. Each device file has a unique path in the device file directory.

[0026] In the embodiments of this disclosure, upon receiving a first callback function registration request initiated by the driver corresponding to the target device, the driver callback function identifier corresponding to the file identifier information and its corresponding driver callback function identifier in the first callback function registration request is registered. The driver callback function identifier in the driver is registered to the first operating system in correspondence with the file identifier information. Device file directories corresponding to each file identifier information are created in the first file system of the first operating system. The device file directories provide an access interface for user space applications to the driver, enabling applications to initiate operation requests for the target device file in the first file system based on the file identifier information of the target device file. The first operating system can accurately call the target driver callback function corresponding to the target device file based on the file identifier information of the target device file and the pre-registered file identifier information and its corresponding driver callback function identifier of the driver, ensuring the accuracy and effectiveness of the access operation to the target device.

[0027] In some alternative embodiments, in the above... Figure 2 Based on the illustrated embodiment, the processor 21 is specifically configured as follows: Based on the operation type and file identifier information of the target device file in the first operation request, the target file operation callback function identifier corresponding to the first operation request is determined from a plurality of pre-registered file operation callback function identifiers; based on the file identifier information of the target device file and the target file operation callback function identifier, a second operation request is generated.

[0028] The operation type refers to the type of operation performed on the target device file corresponding to the first operation request. Operation types include, but are not limited to, read operations, write operations, open file operations, and close file operations.

[0029] The file operation callback function identifier is a unique identifier used to access the file operation callback function of the first file system. Optionally, the file operation callback function identifier is, for example, but not limited to, the function name of the file operation callback function. File operation callback functions include, for example, but not limited to, file read functions (sysfs_read), file write functions (sysfs_write), file open functions (sysfs_open), and file close functions (sysfs_close).

[0030] Optionally, the driver calls a pre-configured registration function to register multiple file operation callback function identifiers and their corresponding file identifier information to the first operating system. Optionally, any file identifier information can correspond to one or more file operation callback function identifiers of different operation types. After obtaining the first operation request, the file identifier information of the target device file in the first operation request is matched with the file identifier information corresponding to the multiple file operation callback function identifiers. The target file identifier information that matches the file identifier information of the target device file is determined from the multiple file identifier information. Based on the operation type in the first operation request, the target operation type of the file operation callback function can be determined. The file operation callback function identifier that corresponds to the target file identifier information and whose operation type is the target operation type is determined as the target file operation callback function identifier.

[0031] After determining the target file operation callback function identifier corresponding to the first operation request, a second operation request can be generated based on the file identifier information of the target device file and the target file operation callback function identifier, according to the request format supported by the first file system, so that the second operation request includes the file identifier information of the target device file and the target file operation callback function identifier.

[0032] In some optional embodiments, opening a file typically precedes a read or write operation, while closing a file typically follows a read or write operation. For example, the application first initiates an open request for a target device file. The first operating system responds to the open request by converting it into a sysfs_open request for accessing the first file system. Based on the sysfs_open request, it executes the corresponding target file operation callback function, initializes data structures related to the target device file, and prepares for subsequent read or write operations. Then, the application initiates a read or write request for the target device file based on its file identifier information (i.e., a first operation request). The first operating system converts this read or write request into a file read or write request for accessing the first file system (i.e., a second operation request). Based on the second operation request, it calls the target driver callback function corresponding to the target device file to perform the access operation to the target device. Optionally, after completing the access operation to the target device, the application can initiate a close operation request for the target device file. The first operating system converts the close operation request into a sysfs_close operation request for accessing the first file system, and executes the corresponding target file operation callback function based on the sysfs_close operation request to release the buffers and data structures related to the target device file. In other words, the file operation steps can include open → read / write → close.

[0033] In the embodiments of this disclosure, based on the operation type in the first operation request and the file identification information of the target device file, the target file operation callback function identifier corresponding to the first operation request can be accurately determined from a plurality of pre-registered file operation callback function identifiers. The target file operation callback function identifier is the identifier of the file operation callback function supported by the first file system. Therefore, based on the file identification information of the target device file and the target file operation callback function identifier, a second operation request for accessing the first file system can be generated, thereby effectively converting the first operation request initiated by the application into a second operation request for accessing the first file system, so as to access the target device file in the first file system through the second operation request, triggering the call to the driver callback function in the driver, and realizing the access operation to the target device.

[0034] In some alternative embodiments, based on any of the above embodiments, the processor 21 is further configured to: Obtain a second function call request from the driver corresponding to the target device to register a function in the virtual file system library, wherein the second function call request includes file identification information; based on the second function call request, initiate a file operation callback function registration request to the device management module in the first operating system by calling the registration function, and register the file identification information and multiple file operation callback function identifiers associated with the file identification information in the virtual file system library to the device management module.

[0035] The processor 21 is specifically configured to: determine the target file operation callback function identifier corresponding to the first operation request from a plurality of file operation callback function identifiers pre-registered in the device management module based on the operation type and the file identifier information of the target device file in the first operation request; and generate a second operation request based on the file identifier information of the target device file and the target file operation callback function identifier.

[0036] In this embodiment, the virtual file system library can be referred to as libsysfs. The virtual file system library is a function library used to access the first file system, and it includes various pre-configured functions. These pre-configured functions include, but are not limited to, registration functions and file operation callback functions. The registration function is used to register the file operation callback function with the device management module (Resource Manager, abbreviated as ResMgr) in the first operating system. The file operation callback function is used to determine the target driver callback function identifier corresponding to the file identifier information of the input target device file; that is, the result of executing the file operation callback function is to return the target driver callback function identifier.

[0037] Optionally, during the initialization phase of the driver startup process, the driver may initiate a second function call request to the first operating system for registering functions in the virtual file system library. Optionally, the driver may generate the second function call request based on the file identification information of each device file associated with the target device, the second function call request including the file identification information of each device file. Optionally, the second function call request may also include the function identifier of the registered function.

[0038] Upon receiving a second function call request, the file identifier information of each device file and the function identifier of the registration function can be determined based on the request. The corresponding registration function is then retrieved from the virtual file system library based on this function identifier, using the file identifier information as parameters. The registration function registers the file identifier information and the associated file operation callback function identifiers from the virtual file system library to the device management module. Specifically, a file operation callback function registration request can be initiated to the device management module by calling the registration function. This request can include the file identifier information and the managed file operation callback function identifiers. In response, the device management module stores the file identifier information and its associated file operation callback function identifiers, thereby registering the file operation callback functions to the device management module. The device management module is the functional software in the first operating system used to manage devices. When the device management module receives a first operation request for a device file from the application, it determines the target file operation callback function identifier corresponding to the first operation request from a plurality of file operation callback function identifiers pre-registered in the first operation request based on the operation type and the file identifier information of the target device file. Based on the file identifier information of the target device file and the target file operation callback function identifier, the device management module generates a second operation request.

[0039] In some optional embodiments, the system kernel in the first operating system may obtain a first operation request from the application, and forward the first operation request to the device management module in the first operating system. The device management module obtains the first operation request, and based on the operation type and file identification information of the target device file in the first operation request, determines the target file operation callback function identifier corresponding to the first operation request from a plurality of file operation callback function identifiers pre-registered in the device management module. Based on the file identification information of the target device file and the target file operation callback function identifier, a second operation request is generated. The virtual file system library responds to the second operation request, executes the target file operation callback function corresponding to the target file operation callback function identifier in the second operation request, determines the target driver callback function identifier, and calls the target driver callback function in the driver program based on the target driver callback function identifier to realize the access operation to the target device.

[0040] In the embodiments of this disclosure, the driver corresponding to the target device initiates a second function call request to the first operating system to register the function in the virtual file system library. By calling the registration function in the virtual file system library, the file identification information related to the target device and the file operation callback function identifier associated with the file identification information in the virtual file system library are registered to the device management module. This enables the device management module to accurately determine the target file operation callback function identifier corresponding to the first operation request based on the file identification information of the target device file in the first operation request when it receives the first operation request from the application. This provides effective reference information for converting the first operation request into a second operation request for accessing the first file system.

[0041] In some optional embodiments, based on any of the above embodiments, the second operation request includes file identification information of the target device file and an identifier of the target file operation callback function. The processor 21 is specifically configured to: Based on the file identifier information of the target device file and the target file operation callback function identifier in the second operation request, the target driver callback function identifier corresponding to the file identifier of the target device file is determined from multiple driver callback function identifiers pre-registered by the driver corresponding to the target device by calling the target file operation callback function corresponding to the target file operation callback function identifier.

[0042] Specifically, the target file operation callback function, based on the file identification information of the input target device file, determines the target driver callback function identifier corresponding to the file identification information of the target device file from a pool of pre-registered driver callback function identifiers. After determining the second operation request, the file identification information and the target file operation callback function identifier of the target device file can be extracted from the second operation request. Based on the target file operation callback function identifier, the corresponding target file operation callback function is retrieved from the virtual file system library. The file identification information of the target device file is used as the parameter of the target file operation callback function, and the target file operation callback function is executed to obtain the execution result. The execution result includes the target driver callback function identifier corresponding to the file identification information of the target device file.

[0043] In the embodiments of this disclosure, based on the target file operation callback function identifier in the second operation request, the target file operation callback function corresponding to the target file operation callback function identifier in the virtual file system library can be obtained. Then, the file identifier information of the target device file is used as the parameter of the target file operation callback function. By calling the target file operation callback function, the target driver callback function identifier corresponding to the file identifier information of the target device file is accurately determined from multiple driver callback function identifiers pre-registered by the driver corresponding to the target device. This provides an accurate and effective target driver callback function identifier for calling the target driver callback function in the driver, ensuring that the access operation to the target device can be successfully executed.

[0044] In some alternative embodiments, based on any of the above embodiments, the processor 21 is specifically configured as follows: Based on the file identifier information of the target device file and the identifier of the target driver callback function, a first function call request is generated to invoke the target driver callback function; in response to the first function call request, the target driver callback function is executed to perform the access operation corresponding to the target driver callback function on the target device.

[0045] After determining the target driver callback function identifier corresponding to the file identifier information of the target device file, a first function call request for invoking the target driver callback function can be generated based on the file identifier information of the target device file and the target driver callback function identifier information. Optionally, the first function call request can be transmitted to the driver program. The driver program responds to the first function call request by retrieving the target driver callback function corresponding to the target driver callback function identifier based on the target driver callback function identifier in the first function call request. The function of the target driver callback function is to read device information such as the status and attributes of the target device, or to update the device information of the target device, thereby enabling access operations to the target device. For example, if the target driver callback function is the `driver_show` function, executing the `driver_show` function reads the device information of the target device and returns the read device information to the application program through the first operating system.

[0046] Optionally, the first operation request initiated by the application may also include other related parameters, such as, but not limited to, one or more of the following: attribute access parameters, data buffer parameters, address of the data to be written, and data length. These parameters can be set according to actual access requirements. Attribute access parameters indicate which attributes of the target device need to be accessed, such as one or more attributes of the target device's status or configuration parameters. Data buffer parameters represent the cache area for the read device information or attributes; that is, the read device information or attributes are cached in the data buffer specified by the application, from which the application can obtain the corresponding device information or attributes. The data to be written is the data that needs to be written to the target device. The address of the data to be written is, for example, but not limited to, the storage address of the data to be written in memory or other storage or registers. Data length indicates the size of the data; based on the address and size of the data to be written, the data to be written can be accurately read from the storage area where it is stored to write it to the target device. In the device access device of this disclosure performing the device access process, various parameters of the first operation request can be passed to subsequent steps as needed to ensure the accuracy and effectiveness of the access operation to the target device. For example, file identification information, attribute access parameters, and data buffer parameters of the target device file in the first operation request can be passed to the second operation request. The application can determine the target device and the range of data to be accessed by setting the parameters of the first operation request. This disclosure does not limit the specific parameters of the first operation request.

[0047] In the embodiments of this disclosure, after determining the target driver callback function identifier, a first function call request for calling the target driver callback function is generated based on the file identifier information of the target device file and the target driver callback function identifier. The target driver callback function corresponding to the target driver callback function identifier in the driver program is accurately called to realize the access operation to the target device and ensure the accuracy and effectiveness of the access operation.

[0048] In some alternative embodiments, based on any of the above embodiments, the processor 21 is further configured to: In response to a third operation request initiated by a user process, based on the first directory information to be operated on in the third operation request, the target directory operation function identifier corresponding to the third operation request is determined from a plurality of pre-registered directory operation function identifiers; based on the first directory information and the target directory operation function identifier, a fourth operation request for accessing the device file directory corresponding to the first file system is constructed according to a preset format; based on the fourth operation request, the directory operation corresponding to the fourth operation request is executed by calling the pre-configured directory operation function corresponding to the target directory operation function identifier, and the operation result corresponding to the third operation request is obtained.

[0049] When a user enters the `ls` or `find` command on a terminal device, the user process can obtain the user's input and initiate a third operation request to the first operating system. The third operation request includes information about the first directory to be operated on. This first directory information is directory information within the first file system. Responding to the third operation request, the first operating system, based on the first directory information in the third operation request, determines the target directory operation function identifier corresponding to the third operation request from a pool of pre-registered target operation function identifiers. Then, based on the first directory information and the target directory operation function identifier, a fourth operation request is constructed according to a preset format for accessing the device file directory corresponding to the first file system. This preset format is a request format supported by the first file system. The fourth operation request includes the first directory information and the target directory operation function identifier. Afterwards, based on the fourth operation request, the directory operation corresponding to the fourth operation request can be executed by calling a pre-configured directory operation function corresponding to the target directory operation function identifier, thus obtaining the operation result corresponding to the third operation request.

[0050] Optionally, the third operation request may include the operation type and the first directory information. The operation type includes, but is not limited to, the open directory (opendir) operation, the read directory (readdir) operation, and the close directory (closedir) operation. The open directory operation is used to open a directory at a specified path. The read directory operation is used to read directory entries, that is, to read the directory entries under the opened directory and return the information structure of the directory entries. Directory entries can be files or subdirectories under that directory. The close directory operation is used to close the directory and release the resources occupied by the directory. The operation results corresponding to the third operation request include, but are not limited to, the operation results corresponding to the open directory operation, the read directory operation, and the close directory operation. The operation result corresponding to the open directory operation includes, but is not limited to, returning the file descriptor of the directory at the specified path, preparing for subsequent read or write operations. The read directory operation includes, but is not limited to, outputting or returning a list of all sub-entries in the directory, including, for example, the names of subdirectories and device files under the subdirectories. The operation result corresponding to the close directory operation includes, but is not limited to, releasing the resources associated with the directory.

[0051] Optionally, the target directory operation function identifier corresponding to the third operation request can be determined from a plurality of pre-registered directory operation function identifiers based on the operation type of the third operation request and the first directory information.

[0052] Optionally, the driver calls the registration function in the virtual file system library to register the directory operation function identifiers corresponding to multiple directory operation functions in the virtual file system library with the device management module in the first operating system. The system kernel in the first operating system responds to the third operation request initiated by the user process and sends the third operation request to the device management module. Based on the operation type and first directory information in the third operation request, the device management module determines the target directory operation function identifier corresponding to the third operation request from the pre-registered multiple directory operation function identifiers. Based on the first directory information and the target directory operation function identifier, a fourth operation request for accessing the device file directory corresponding to the first file system is generated and transmitted to the virtual file system library. The virtual file system library, based on the target directory operation function identifier in the fourth operation request, determines the directory operation function corresponding to the target directory operation function identifier, uses the first directory information as the parameter of the directory operation function, executes the directory operation function, performs the corresponding directory operation, and obtains the operation result corresponding to the third operation request.

[0053] Optionally, the directory operation functions can be operation functions pre-configured in the virtual file system library for accessing device file directories of the first file system. These directory operation functions include, but are not limited to, directory open (sysfs_opendir), directory read (sysfs_readdir), and directory close (sysfs_closedir) operation functions adapted to the first file system. Since the directory operation functions operate on device file directories in the first file system, they do not require interaction with the driver; directory operations on the device file directories are achieved by executing the target operation functions.

[0054] Optionally, the function name of a directory operation function for any operation type in the virtual file system library can be the same as or different from the function name of the file operation callback function for the same operation type. For example, for the open operation type, the function name of the directory operation function is sysfs_open, and the function name of the file operation callback function is also sysfs_open. In the case where the function names of the directory operation function and the file operation callback function are the same, the parameters of the sysfs_open function can be used to distinguish between directory and file operations. For example, a flag parameter can be set to indicate whether the type of the operation object is a file or a directory. In this way, file and directory operations can call the same function, implementing directory or file operations by passing different parameters.

[0055] Optionally, the third operation request may also include other parameters related to the directory operation, such as, but not limited to, data buffer parameters. After the directory operation function corresponding to the target directory operation function identifier in the virtual file system library is executed, the read result is written to the buffer corresponding to the data buffer parameter.

[0056] In the embodiments of this disclosure, when a user process initiates a third operation request, the target directory operation function identifier corresponding to the third operation request can be determined from a plurality of pre-registered directory operation function identifiers based on the first directory information in the third operation request. Then, based on the first directory information and the target directory operation function identifier, a fourth operation request for accessing the device file directory corresponding to the first file system can be constructed according to a preset format supported by the first file system. This effectively converts the third operation request initiated by the user process into a fourth operation request that can access the first file system. Based on the fourth operation request, the corresponding directory operation function is called to implement the corresponding directory operation, providing the user with the function of viewing the device file directory or files under the directory.

[0057] In some alternative embodiments, Figure 3 This is a schematic diagram of the software architecture of an access device for a device provided in an exemplary embodiment of this disclosure. For example... Figure 3As shown, taking the QNX operating system as an example, the software architecture of the device access device 20 may include an application program (APP) 31, a user process 32, a system kernel 33, a device management module (ResMgr) 34, a virtual file system library (libsysfs) 35, a driver 36, and a first file system 37. During driver initialization, the driver 36 registers its driver callback function identifier with the virtual file system library 35. The driver 36 also calls the registration function in the virtual file system library 35 to register the file operation callback function identifier and directory operation function identifier in the virtual file system library 35 with the device management module 34. In response to the registration request, the device management module 34 stores the file identifier information and its corresponding file operation callback function identifier, as well as the directory operation function, and creates a device file directory in the first file system. After the driver initialization is complete, the application 31 can initiate a first operation request to the system kernel 33 based on the file identification information of the target device file. The system kernel 33 forwards the first operation request to the device management module 34. The device management module 34 converts the first operation request into a second operation request for accessing the first file system and transmits the second operation request to the virtual file system library 35. Based on the second operation request, the target file operation callback function in the virtual file system library 35 is called to determine the target driver callback function identifier corresponding to the file identification information of the target device file. Based on the target driver callback function identifier and the file identification information of the target device file, a first function call request is generated and transmitted to the driver 36. The driver 36 responds to the first function call request, executes the target driver callback function, performs the access operation corresponding to the target driver callback function on the target device, and returns the access result to the application 31 through the virtual file system library 35, the device association module 34, and the system kernel 33. When user process 32 initiates a third operation request, system kernel 33 can obtain the third operation request of user process 32 and forward it to device management module 34. Device management module 34 converts the third operation request into a fourth operation request for accessing the first file system. Based on the fourth operation request, it calls the pre-configured directory operation function in virtual file system library 35 to perform the directory operation corresponding to the fourth operation request, obtains the operation result, and returns the operation result to user process 32 through device management module 34 and system kernel 33 so that user process 32 can display the operation result to the user.

[0058] In related technologies, the QNX operating system lacks the functionality of the virtual file system library 35 and does not support the first file system. Therefore, drivers need to be redesigned specifically for the QNX operating system, and applications manage device access through the device management module. For example, when an application initiates an open operation request, the process manager searches for the corresponding device manager in the namespace. The device manager then interacts with the redesigned driver to access the device.

[0059] The device access device provided in this embodiment adds a virtual file system library 35 to the QNX operating system, enabling the QNX operating system to support a first file system. This allows the first file system to run within the QNX operating system. The device management module converts operation requests from applications and user processes into operation requests for accessing the first file system. The access operation to the first file system triggers a call to the driver callback function in the driver program. By executing the driver callback function, the device access operation is achieved. Thus, the driver program designed for a second operating system that supports the first file system can be reused, avoiding the need to redesign the driver program for the QNX operating system.

[0060] It should be noted that in practical applications, the device access functions disclosed herein and the original device access functions of the first operating system can also be compatible in the first operating system, providing users with different functions. This allows users to redesign drivers or reuse drivers supported by the second operating system according to their needs, effectively improving the user experience.

[0061] The embodiments described above can be implemented individually or in any combination without conflict. The specific implementation can be set according to actual needs, and this disclosure does not limit them.

[0062] Exemplary methods Figure 4 This is a schematic flowchart of a device access method provided in an exemplary embodiment of this disclosure. The device access method provided in this embodiment can be implemented using any of the device access devices provided in the above embodiments of this disclosure, such as... Figure 4 The method for accessing the device shown may include the following steps: Step 510: In the first operating system, obtain the first operation request initiated by the application for the target device file.

[0063] Step 520: Based on the file identification information of the target device file in the first operation request, determine the second operation request for accessing the first file system.

[0064] The first file system is a preset type of file system supported by the second operating system; the first file system includes multiple device files corresponding to multiple file identification information.

[0065] Step 530: Based on the second operation request, determine the target driver callback function identifier that corresponds to the file identifier information of the target device file from among the multiple driver callback function identifiers pre-registered by the driver corresponding to the target device.

[0066] Step 540: Perform an access operation on the target device by calling the target driver callback function corresponding to the target driver callback function identifier in the driver program.

[0067] Figure 5 This is a flowchart illustrating a device access method provided in another exemplary embodiment of this disclosure.

[0068] In some alternative embodiments, based on any of the above embodiments, such as Figure 5 As shown, the method in this embodiment of the disclosure further includes: Step 610: Obtain the first callback function registration request initiated by the driver corresponding to the target device.

[0069] Step 620: Based on the file identifier information to be registered and its corresponding driver callback function identifier in the first callback function registration request, perform the registration of the driver callback function identifier corresponding to the file identifier information, and create a device file directory corresponding to the file identifier information in the first file system.

[0070] Figure 6 This is a flowchart illustrating a device access method provided in another exemplary embodiment of this disclosure.

[0071] In some alternative embodiments, based on any of the above embodiments, such as Figure 6 As shown, step 520, which determines the second operation request for accessing the first file system based on the file identifier information of the target device file in the first operation request, may include: Step 5210: Based on the operation type and file identifier information of the target device file in the first operation request, determine the target file operation callback function identifier corresponding to the first operation request from a plurality of pre-registered file operation callback function identifiers.

[0072] Step 5220: Generate a second operation request based on the file identification information of the target device file and the target file operation callback function identifier.

[0073] Figure 7 This is a flowchart illustrating a device access method provided in yet another exemplary embodiment of this disclosure.

[0074] In some alternative embodiments, based on any of the above embodiments, such as Figure 7 As shown, the method in this embodiment of the disclosure may further include: Step 710: Obtain the second function call request initiated by the driver corresponding to the target device for the registration function in the virtual file system library.

[0075] The second function call request includes file identification information.

[0076] Step 720: Based on the second function call request, a file operation callback function registration request is initiated to the device management module in the first operating system by calling the registration function, and the file identification information and multiple file operation callback function identifiers associated with the file identification information in the virtual file system library are registered to the device management module.

[0077] Step 520, based on the file identifier information of the target device file in the first operation request, determines the second operation request for accessing the first file system, which may include: Based on the operation type and file identifier information of the target device file in the first operation request, the target file operation callback function identifier corresponding to the first operation request is determined from multiple file operation callback function identifiers pre-registered in the device management module. Based on the file identifier information of the target device file and the target file operation callback function identifier, a second operation request is generated.

[0078] In some optional embodiments, the second operation request includes file identification information of the target device file and the target file operation callback function identifier.

[0079] In step 530, based on the second operation request, the target driver callback function identifier corresponding to the file identifier information of the target device file is determined from among multiple driver callback function identifiers pre-registered by the driver corresponding to the target device. This may include: Based on the file identifier information of the target device file and the target file operation callback function identifier in the second operation request, the target driver callback function identifier corresponding to the file identifier of the target device file is determined from multiple driver callback function identifiers pre-registered by the driver corresponding to the target device by calling the target file operation callback function corresponding to the target file operation callback function identifier.

[0080] Figure 8 This is a flowchart illustrating a device access method provided in another exemplary embodiment of this disclosure.

[0081] In some alternative embodiments, based on any of the above embodiments, such as Figure 8As shown, step 540, which involves calling the target driver callback function corresponding to the target driver callback function identifier in the driver program to perform an access operation on the target device, may include: Step 5410: Based on the file identification information of the target device file and the target driver callback function identifier, generate a first function call request for calling the target driver callback function.

[0082] Step 5420: In response to the first function call request, execute the target driver callback function to perform the access operation corresponding to the target driver callback function on the target device.

[0083] Figure 9 This is a flowchart illustrating a device access method provided in yet another exemplary embodiment of this disclosure.

[0084] In some alternative embodiments, based on any of the above embodiments, such as Figure 9 As shown, the method in this embodiment of the disclosure may further include: Step 810: In response to the third operation request initiated by the user process, based on the first directory information to be operated on in the third operation request, determine the target directory operation function identifier corresponding to the third operation request from a plurality of pre-registered directory operation function identifiers.

[0085] Step 820: Based on the first directory information and the target directory operation function identifier, construct a fourth operation request for accessing the device file directory corresponding to the first file system according to a preset format.

[0086] Step 830: Based on the fourth operation request, the directory operation corresponding to the fourth operation request is executed by calling the pre-configured directory operation function corresponding to the target directory operation function identifier, and the operation result corresponding to the third operation request is obtained.

[0087] The embodiments described above can be implemented individually or in any combination without conflict. The specific implementation can be set according to actual needs, and this disclosure does not limit them.

[0088] The beneficial technical effects corresponding to the exemplary embodiments of this method can be found in the corresponding beneficial technical effects of the exemplary device section above, and will not be repeated here.

[0089] The device access method provided in this disclosure can be executed by any suitable electronic device with data processing capabilities, including but not limited to terminal devices and servers. Alternatively, the device access method provided in this disclosure can be executed by a processor, which executes the device access method mentioned in this disclosure by calling corresponding instructions stored in memory. Further details will not be elaborated below.

[0090] Exemplary electronic devices Figure 10 This is a structural diagram of an electronic device provided in an embodiment of the present disclosure, including at least one processor 91 and a memory 92.

[0091] The processor 91 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 90 to perform desired functions.

[0092] The memory 92 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 91 may execute one or more computer program instructions to implement the access methods and / or other desired functions of the devices of the various embodiments of this disclosure described above.

[0093] In one example, the electronic device 90 may also include an input device 93 and an output device 94, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0094] The input device 93 may also include, for example, a touch screen, a microphone, various sensors, etc.

[0095] The output device 94 can output various information to the outside, including, for example, a display, a speaker, a communication network and its connected remote output devices, etc.

[0096] Of course, for the sake of simplicity, Figure 10 Only some of the components of the electronic device 90 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 90 may include any other suitable components depending on the specific application.

[0097] Exemplary computer program products and computer-readable storage media In addition to the methods and apparatus described above, embodiments of this disclosure may also provide a computer program product, including computer program instructions that, when executed by a processor, cause the processor to perform the steps of the device access methods of various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0098] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of embodiments of this disclosure. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0099] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps of the device access methods of various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0100] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, but is not limited to, systems, apparatuses, or devices that are electrical, magnetic, optical, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0101] The basic principles of this disclosure have been described above with reference to specific embodiments. However, the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0102] Various modifications and variations can be made to this disclosure without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.

Claims

1. An access device for a device, the device comprising a processor configured to: In the first operating system, obtain the first operation request initiated by the application for the target device file; Based on the file identifier information of the target device file in the first operation request, a second operation request for accessing the first file system is determined, wherein... The first file system is a preset type of file system supported by the second operating system; the first file system includes multiple device files corresponding to multiple file identification information respectively; Based on the second operation request, the target driver callback function identifier corresponding to the file identifier information of the target device file is determined from among the multiple driver callback function identifiers pre-registered by the driver corresponding to the target device. An access operation is performed on the target device by calling the target driver callback function in the driver program that corresponds to the target driver callback function identifier.

2. The apparatus according to claim 1, wherein, The processor is specifically configured as follows: Based on the operation type in the first operation request and the file identifier information of the target device file, the target file operation callback function identifier corresponding to the first operation request is determined from a plurality of pre-registered file operation callback function identifiers; The second operation request is generated based on the file identification information of the target device file and the target file operation callback function identifier.

3. The apparatus according to claim 1, wherein, The processor is also configured to: Obtain a second function call request initiated by the driver corresponding to the target device to register a function in the virtual file system library, wherein the second function call request includes file identification information; Based on the second function call request, by calling the registration function, a file operation callback function registration request is initiated to the device management module in the first operating system, and the file identification information and multiple file operation callback function identifiers associated with the file identification information in the virtual file system library are registered to the device management module; The processor is specifically configured as follows: Based on the operation type in the first operation request and the file identifier information of the target device file, the target file operation callback function identifier corresponding to the first operation request is determined from a plurality of file operation callback function identifiers pre-registered in the device management module; The second operation request is generated based on the file identification information of the target device file and the target file operation callback function identifier.

4. The apparatus according to claim 1, wherein, The second operation request includes the file identification information of the target device file and the target file operation callback function identifier; The processor is specifically configured as follows: Based on the file identifier information of the target device file and the target file operation callback function identifier in the second operation request, the target driver callback function identifier corresponding to the file identifier information of the target device file is determined from a plurality of driver callback function identifiers pre-registered by the driver corresponding to the target device by calling the target file operation callback function corresponding to the target file operation callback function identifier.

5. The apparatus according to claim 1, wherein, The processor is specifically configured as follows: Based on the file identification information of the target device file and the identifier of the target driver callback function, a first function call request for calling the target driver callback function is generated; In response to the first function call request, the target driver callback function is executed to perform an access operation on the target device corresponding to the target driver callback function.

6. The apparatus according to claim 1, wherein, The processor is also configured to: In response to a third operation request initiated by a user process, based on the first directory information to be operated on in the third operation request, the target directory operation function identifier corresponding to the third operation request is determined from a plurality of pre-registered directory operation function identifiers; Based on the first directory information and the target directory operation function identifier, a fourth operation request for accessing the device file directory corresponding to the first file system is constructed according to a preset format. Based on the fourth operation request, the directory operation corresponding to the fourth operation request is executed by calling the pre-configured directory operation function corresponding to the target directory operation function identifier, and the operation result corresponding to the third operation request is obtained.

7. The apparatus according to any one of claims 1 to 6, wherein, The processor is also configured to: Obtain the first callback function registration request initiated by the driver corresponding to the target device; Based on the file identifier information to be registered and its corresponding driver callback function identifier in the first callback function registration request, the registration of the driver callback function identifier corresponding to the file identifier information is performed, and a device file directory corresponding to the file identifier information is created in the first file system.

8. A method for accessing a device, comprising: In the first operating system, obtain the first operation request initiated by the application for the target device file; Based on the file identification information of the target device file in the first operation request, a second operation request for accessing the first file system is determined, wherein the first file system is a preset type of file system supported by the second operating system; the first file system includes multiple device files corresponding to multiple file identification information respectively; Based on the second operation request, the target driver callback function identifier corresponding to the file identifier information of the target device file is determined from among the multiple driver callback function identifiers pre-registered by the driver corresponding to the target device. An access operation is performed on the target device by calling the target driver callback function in the driver program that corresponds to the target driver callback function identifier.

9. The method according to claim 8, wherein, The step of determining a second operation request for accessing the first file system based on the file identifier information of the target device file in the first operation request includes: Based on the operation type in the first operation request and the file identifier information of the target device file, the target file operation callback function identifier corresponding to the first operation request is determined from a plurality of pre-registered file operation callback function identifiers; The second operation request is generated based on the file identification information of the target device file and the target file operation callback function identifier.

10. The method according to claim 8, wherein, Also includes: Obtain a second function call request initiated by the driver corresponding to the target device to register a function in the virtual file system library, wherein the second function call request includes file identification information; Based on the second function call request, by calling the registration function, a file operation callback function registration request is initiated to the device management module in the first operating system, and the file identification information and multiple file operation callback function identifiers associated with the file identification information in the virtual file system library are registered to the device management module; The step of determining a second operation request for accessing the first file system based on the file identifier information of the target device file in the first operation request includes: Based on the operation type in the first operation request and the file identifier information of the target device file, the target file operation callback function identifier corresponding to the first operation request is determined from a plurality of file operation callback function identifiers pre-registered in the device management module; The second operation request is generated based on the file identification information of the target device file and the target file operation callback function identifier.

11. The method according to claim 8, wherein, The second operation request includes the file identification information of the target device file and the target file operation callback function identifier; The step of determining the target driver callback function identifier corresponding to the file identifier information of the target device file from among multiple driver callback function identifiers pre-registered by the driver corresponding to the target device based on the second operation request includes: Based on the file identifier information of the target device file and the target file operation callback function identifier in the second operation request, the target driver callback function identifier corresponding to the file identifier information of the target device file is determined from a plurality of driver callback function identifiers pre-registered by the driver corresponding to the target device by calling the target file operation callback function corresponding to the target file operation callback function identifier.

12. The method according to claim 8, wherein, The step of performing an access operation on the target device in the first file system by calling the target driver callback function corresponding to the target driver callback function identifier in the driver includes: Based on the file identification information of the target device file and the identifier of the target driver callback function, a first function call request for calling the target driver callback function is generated; In response to the first function call request, the target driver callback function is executed to perform an access operation on the target device corresponding to the target driver callback function.

13. The method according to claim 1, wherein, Also includes: In response to a third operation request initiated by a user process, based on the first directory information to be operated on in the third operation request, the target directory operation function identifier corresponding to the third operation request is determined from a plurality of pre-registered directory operation function identifiers; Based on the first directory information and the target directory operation function identifier, a fourth operation request for accessing the device file directory corresponding to the first file system is constructed according to a preset format. Based on the fourth operation request, the directory operation corresponding to the fourth operation request is executed by calling the pre-configured directory operation function corresponding to the target directory operation function identifier, and the operation result corresponding to the third operation request is obtained.

14. The method according to any one of claims 8 to 13, wherein, Also includes: Obtain the first callback function registration request initiated by the driver corresponding to the target device; Based on the file identifier information to be registered and its corresponding driver callback function identifier in the first callback function registration request, the registration of the driver callback function identifier corresponding to the file identifier information is performed, and a device file directory corresponding to the file identifier information is created in the first file system.

15. A computer-readable storage medium storing a computer program that is executed by a processor to perform the access method of the device according to any one of claims 8 to 14.

16. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory, and execute the executable instructions to implement the device access method according to any one of claims 8 to 14.

Images