Two-way data transmission method based on single-device file and related device

Abstract

Embodiments of the present application disclose a two-way data transmission method based on a single device file and a related device. In the method, only a single target character device file is set as the only interface for interaction between a user-mode application and direct memory access hardware, and the user-mode application only needs to maintain a set of file descriptors to simultaneously complete two types of transmission requests, i.e., sending and receiving, without separately operating two independent device files, thereby greatly reducing the number of error handling branches. Moreover, the receiving and the sending are respectively configured with independent direct memory access engines and independent data channels, the two-way transmission resources are physically isolated, and single-direction transmission failure does not interfere with the normal work of the other direction, thereby further reducing the probability of overall transmission failure caused by single-direction abnormal expansion, and effectively improving the reliability of data transmission.

Description

Technical Field

[0001] This application relates to the field of data transmission technology, and more specifically, to a bidirectional data transmission method and related apparatus based on a single device file. Background Technology

[0002] In embedded data transmission architectures, since user-mode applications cannot directly access the underlying DMA (Direct Memory Access) hardware registers, character device files are typically used as an intermediary for interaction between user space and kernel hardware drivers. However, in related technologies, DMA transfers in the sending and receiving directions are usually registered as separate character device files. User-mode applications need to open different device files for sending and receiving operations, which easily leads to device file synchronization problems, cumbersome device file management, and significantly increased complexity and error risk, resulting in poor data transmission reliability. Therefore, improving data transmission reliability is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0003] The embodiments of this application provide a bidirectional data transmission method and related apparatus based on a single device file to solve the problem of poor data transmission reliability.

[0004] According to one aspect of the embodiments of this application, a bidirectional data transmission method based on a single device file is provided, comprising: responding to a data transmission request from a user-mode application, obtaining device context information through a single target character device file, wherein the single target character device file serves as the unique interface between the user-mode application and direct memory access hardware; extracting a direct memory access engine corresponding to the data transmission request from the device context information; wherein the direct memory access engine includes a sending engine and a receiving engine, and the step of extracting the direct memory access engine corresponding to the data transmission request from the device context information comprises: if the data transmission request is a sending request, extracting the sending engine from the device context information; if the data transmission request is a receiving request, extracting the receiving engine from the device context information; and sending the data transmission request to the direct memory access engine through a preset submission function, so as to transmit data through an independent data channel corresponding to the direct memory access engine.

[0005] In one implementation, the step of sending the data transmission request to the Direct Memory Access Engine (DMI) via a preset submission function to transmit data through the independent data channel corresponding to the DMI includes: obtaining initial transmission parameters and a Boolean parameter indicating the data transmission direction; performing an alignment check on the initial transmission parameters, the Boolean parameter, and the DMI to obtain an alignment check result; wherein the initial transmission parameters include the single target character device file, the user-mode buffer address, the transmission data length, and the current file offset; if the alignment check result indicates that all checks have passed, then performing buffer mapping based on the Boolean parameter to obtain a hash table of physical address information corresponding to the transmission buffer; and calling the preset submission function to send a data transmission task carrying the Boolean parameter, the current file offset, and the hash table to the independent data channel corresponding to the DMI, so as to transmit data through the independent data channel corresponding to the DMI.

[0006] In one implementation, the direct memory access engine includes a sending engine and a receiving engine, the transmission buffer includes a sending buffer and a receiving buffer, and the step of mapping the buffers according to the Boolean parameter to obtain a hash table of physical address information corresponding to the transmission buffer includes: if the data transmission direction represented by the Boolean parameter is the sending direction, then performing buffer mapping from the independent memory pool corresponding to the sending engine to obtain a hash table of physical address information corresponding to the sending buffer; if the data transmission direction represented by the Boolean parameter is the receiving direction, then performing buffer mapping from the independent memory pool corresponding to the receiving engine to obtain a hash table of physical address information corresponding to the receiving buffer.

[0007] In one embodiment, the method further includes: if the data transmission direction represented by the Boolean parameter is the sending direction, then the sending buffer is directly released after the data transmission is completed, and the data transmission result is returned; if the data transmission direction represented by the Boolean parameter is the receiving direction, then the data in the receiving buffer is copied to the user-mode buffer after the data transmission is completed, the receiving buffer is released, and the data transmission result is returned.

[0008] In one embodiment, the method further includes: in response to a descriptor allocation request, acquiring a mutex lock corresponding to the direct memory access engine; wherein the mutex locks corresponding to different direct memory access engines are independent of each other; when the current thread is in the state of holding the mutex lock, querying a free descriptor from a preset descriptor table, marking the free descriptor as occupied, and releasing the mutex lock after marking; when the data transmission is completed, in response to a descriptor reclamation request, acquiring the mutex lock; when the current thread is in the state of holding the mutex lock, marking the descriptor that has completed data transmission as unoccupied, and releasing the mutex lock after marking.

[0009] In one embodiment, the method further includes: when it is necessary to modify the transfer queue corresponding to the direct memory access engine, acquiring the spinlock corresponding to the direct memory access engine; wherein the spinlocks corresponding to different direct memory access engines are independent of each other; while the current thread is in the state of holding the spinlock, modifying the transfer queue, and releasing the spinlock after the modification operation is completed.

[0010] According to one aspect of the embodiments of this application, a bidirectional data transmission device based on a single device file is provided, comprising: a first acquisition module, a second acquisition module, and a data transmission module; wherein, the first acquisition module is configured to, in response to a data transmission request from a user-mode application, acquire device context information through a single target character device file, the single target character device file serving as the unique interface between the user-mode application and direct memory access hardware; the second acquisition module is configured to extract the direct memory access engine corresponding to the data transmission request from the device context information; and the data transmission module is configured to send the data transmission request to the direct memory access engine through a preset submission function, so as to transmit data through an independent data channel corresponding to the direct memory access engine.

[0011] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the bidirectional data transmission method based on a single device file as described above.

[0012] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the bidirectional data transfer method based on a single device file as described above.

[0013] In the technical solution provided by the embodiments of this application, by setting only a single target character device file as the sole interface for interaction between the user-mode application and the direct memory access hardware, the user-mode application only needs to maintain one set of file descriptors to simultaneously complete both sending and receiving transmission requests, without having to operate on two separate device files, thus significantly reducing the number of error handling branches. Furthermore, by dynamically extracting the sending engine or receiving engine that matches the data transmission request type using device context information, automatic identification of the transmission direction is achieved, avoiding the security risks caused by direct operation of the hardware channel by the user-mode. The sending and receiving are configured with independent direct memory access engines and independent data channels, and the bidirectional transmission resources are physically isolated. A transmission failure in one direction will not interfere with the normal operation in the other direction, further reducing the probability of unidirectional anomaly propagation leading to overall transmission failure, thereby effectively improving the reliability of data transmission.

[0014] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0016] Figure 1 This is a schematic diagram illustrating an implementation environment of the bidirectional data transmission method based on a single device file, as shown in an exemplary embodiment of this application. Figure 2 This is a flowchart illustrating a bidirectional data transfer method based on a single device file, as shown in an exemplary embodiment of this application; Figure 3 yes Figure 2 The flowchart of step S230 in the illustrated embodiment, which implements a method for data transmission in an exemplary embodiment, is shown. Figure 4 yes Figure 3 The flowchart of step S320 in the illustrated embodiment is a method for performing buffer mapping in an exemplary embodiment; Figure 5 This is a flowchart illustrating a data transmission method in another exemplary embodiment of this application; Figure 6 This is a flowchart illustrating a method for data transmission using a locking mechanism, as shown in an exemplary embodiment of this application. Figure 7This is a flowchart illustrating a method for concurrent protection of a transmission queue during data transmission, as shown in an exemplary embodiment of this application. Figure 8 This is a schematic diagram illustrating the code implementation for defining a device context, as shown in an exemplary embodiment of this application. Figure 9 This is a schematic diagram illustrating the code implementation of registering a single-target character device file operation set, as shown in an exemplary embodiment of this application. Figure 10 This is a schematic diagram illustrating the code implementation of a write operation in an exemplary embodiment of this application; Figure 11 This is a schematic diagram illustrating the code implementation of a read operation in an exemplary embodiment of this application; Figure 12 This is a schematic diagram illustrating the code implementation of calling a preset submission function, as shown in an exemplary embodiment of this application; Figure 13 This is a schematic diagram illustrating the structure of a bidirectional data transmission device based on a single device file, as shown in an exemplary embodiment of this application. Figure 14 This is a schematic diagram of the structure of a computer system suitable for implementing the electronic devices of the present application embodiments. Detailed Implementation

[0017] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments identical to those described in this application. Rather, they are merely examples of apparatuses and methods identical to some aspects of this application as detailed in the appended claims.

[0018] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented as application programs, in one or more hardware modules or integrated circuits, or in different models and / or processor devices and / or microcontroller devices.

[0019] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0020] It should be noted that "multiple" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0021] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows: In an operating system, user mode and kernel mode are two distinct execution environments, primarily differing in permissions and the types of operations they can perform. User mode is the runtime environment for ordinary user programs, which has limited access to system resources, cannot directly manipulate hardware devices, and cannot perform operations that might affect system stability. Kernel mode, on the other hand, is the runtime environment for the operating system's core code, possessing full access to all hardware resources and the ability to execute any CPU instruction.

[0022] In some embodiments, a user-mode application is used to instruct a program running in the user space (i.e., user mode) of a computer system, which may be used, but is not limited to, to interact with the kernel through system calls to access hardware resources in the computer system, thereby enabling read and write operations.

[0023] Character device files are file-based entry points provided by the Linux operating system to user-space applications. They are mapped to character device drivers registered in the kernel via the VFS (Virtual File System). A character device file is a device node that reads and writes bytes sequentially, without fixed block size, without disk caching, and located in the / dev / directory. Its type is identified as c (character). In related technologies, DMA transfers in the sending and receiving directions are typically registered as separate character devices to manage data transfer channels and control logic in different directions.

[0024] The sending (tx) direction refers to the direction of data transmission from the host memory to the external device.

[0025] The receive (rx) direction refers to the direction of data transfer from the external device to the host memory.

[0026] A Direct Memory Access (DMA) engine is a hardware device or subsystem used to implement direct memory access in a computer system. In computer systems, data transfer typically requires the CPU as an intermediary; data is transferred from a device to memory and then back again. This consumes CPU processing power and reduces system efficiency. To improve data transfer efficiency, DMA engines were introduced into computer systems. A DMA engine can directly read or write data from a device to memory without the CPU's intervention. It can independently control the data transfer process, enabling direct data transfer between devices and memory. In some embodiments, a DMA engine includes a DMA send engine and a DMA receive engine.

[0027] The DMA transfer engine is used to manage data transfer from host memory to external devices.

[0028] The DMA receive engine is used to manage data transfer from external devices to host memory.

[0029] The default commit function is a unified commit interface function for handling DMA reads / DMA writes. It controls the transfer direction and the DMA engine used through parameters, rather than implementing two separate sets of logic for reads and writes. In some embodiments, the default commit function can be represented as the `dev_sgdma_read_write_with_engine()` function.

[0030] In related technologies, during data transmission, DMA transfers in the sending and receiving directions are typically registered as independent character device files. User-space applications need to open different device files separately for sending and receiving operations. This easily leads to device file synchronization problems, cumbersome device file management, and significantly increases complexity and error risk, resulting in poor data transmission reliability. Therefore, how to improve data transmission reliability is a technical problem that urgently needs to be solved by those skilled in the art.

[0031] Based on this, embodiments of this application provide a bidirectional data transmission method and apparatus, electronic device, and computer-readable storage medium based on a single device file, which can solve the problem of poor chip verification efficiency. The implementation environment of the bidirectional data transmission method based on a single device file provided in this application embodiment is described below.

[0032] This application provides a bidirectional data transfer scheme based on a single device file, which can be applied to, for example... Figure 1 In the implementation environment shown, such as Figure 1As shown, the bidirectional data transmission environment based on a single device file provided in this application includes a terminal 110 and a server 120. The bidirectional data transmission scheme based on a single device file provided in this application can be executed by either the terminal 110 or the server 120, or it can be executed collaboratively by the terminal 110 and the server 120. The terminal 110 and the server 120 can communicate via a network. This network can be a wired network or a wireless network. Therefore, the terminal 110 and the server 120 can be directly or indirectly connected via wired or wireless communication. For example, the terminal 110 can be indirectly connected to the server 120 via a wireless access point, or the terminal 110 can be directly connected to the server 120 via the Internet; this application does not impose any limitations on this.

[0033] Among them, terminal 110 may be, but is not limited to, mobile phones, tablets, wearable devices (such as smart rings, watches, bracelets, smart helmets, etc.), in-vehicle devices, smart home devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc.

[0034] In some embodiments, the terminal 110 is provided with a human-computer interaction interface, which is used to provide an interface for human-computer interaction functions / an interface for displaying data transmission results. For example, a graphical user interface (GUI) display, such as an augmented reality (AR) interface, a virtual reality (VR) interface, a voice user interface (VUI), an interactive projection interface (using projection technology to display information on a plane), an eye-tracking interface (an interface controlled by detecting the user's gaze), a holographic interface (a three-dimensional hologram formed by projecting images using holographic projection technology, which can be seen without wearing special glasses), a multimodal interface (an interactive interface that combines multiple interaction methods, such as tactile, visual, and auditory interaction), a brain-machine interface (BMI), etc.

[0035] Server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Different services can be deployed on the same server or on different servers. The data storage system can store the data that server 120 needs to process. This data storage system can be set up independently, integrated into server 120, or placed in the cloud or on other servers. It should be noted that... Figure 1 The number of terminals and servers is for illustrative purposes only and does not constitute an actual limitation of this application.

[0036] The following will combine Figure 2 The bidirectional data transmission method based on a single device file provided in the embodiments of this application will be described in detail.

[0037] Please see Figure 2 , Figure 2 This is a flowchart illustrating a bidirectional data transfer method based on a single device file, as shown in an exemplary embodiment of this application. The method can be executed by a computer device, which can be... Figure 1 The example shown is of a terminal in the implementation environment. Of course, this method can also be applied to other implementation environments and executed by terminals in other implementation environments; this embodiment does not limit this.

[0038] like Figure 2 As shown, in an exemplary embodiment, the bidirectional data transfer method based on a single device file includes at least steps S210 to S230, which are described in detail below: In step S210, in response to a data transfer request from a user-mode application, device context information is obtained through a single target character device file, which serves as the sole interface between the user-mode application and the direct memory access hardware.

[0039] In operating systems (such as Linux), a character device file is a special file representing a character device. Located in a specified directory (e.g., / dev), it does not store physical disk data but serves as an interface between user-mode applications and kernel character device drivers. Therefore, in this embodiment, the single-target character device file refers to the unique interface between the user-mode application and direct memory access hardware; that is, both sending and receiving operations of the user-mode application are implemented through this single-target character device file.

[0040] In some embodiments, the single-target character device file is created and registered in advance by the driver in the operating system kernel as a standard character device kernel object `struct cdev`. This registers the character device and generates a virtual file node corresponding to the `struct cdev` in the ` / dev` directory, i.e., the single-target character device file. By setting only a single-target character device file as the sole interface between user-mode applications and direct memory access hardware, user-mode applications only need to maintain one set of file descriptors to simultaneously complete both sending and receiving transmission requests, eliminating the need to operate on two separate device files and significantly reducing the number of error handling branches.

[0041] In some embodiments, the device context information in this application is located in a custom kernel structure. It is used to uniquely bind a hardware instance, store all the operating states of the hardware, and associate all underlying operating resources; it is the core data carrier for the driver layer to manage the hardware. For example, the device context information includes a pointer to the direct memory access engine, a global instance pointer to the hardware controller, and other members (such as permissions, buffers, task queues, session states, etc.).

[0042] For example, in this embodiment, device context information can be directly read from the private data corresponding to a single target character device file. By caching the device context information in the private data, the DMA engine can be directly accessed via pointers during data transfer, eliminating the need to parse the device number again or perform a structure lookup, thus significantly reducing kernel computational overhead and DMA transfer latency.

[0043] Step S220: Extract the direct memory access engine corresponding to the data transmission request from the device context information.

[0044] In this embodiment, the direct memory access engine includes a DMA send engine and a DMA receive engine. The DMA send engine manages data transfer from host memory to external devices, and the DMA receive engine manages data transfer from external devices to host memory.

[0045] In some embodiments, data transfer requests include different types, such as send type requests and receive type requests. A send type request is used to write data from a user-space application to an external device; a receive type request is used to read data from an external device to a user-space application. Therefore, if the data transfer request is a send type request, the corresponding direct memory access engine is a DMA send engine; if the data transfer request is a receive type request, the corresponding direct memory access engine is a DMA receive engine.

[0046] In some embodiments, the direct memory access engine includes a sending engine and a receiving engine. In this application embodiment, the direct memory access engine corresponding to the data transmission request can be extracted from the device context information through the following process: Step S221: If the data transmission request is a send request, then the send engine is extracted from the device context information.

[0047] Step S222: If the data transmission request is a receive request, then extract the receive engine from the device context information.

[0048] In this embodiment, the direct memory access engine within the device context is precisely matched based on the transmission request type, achieving targeted binding between transmission services and hardware engines. Leveraging the device context's session isolation feature, the send / receive engine resources of different application sessions are independent and do not interfere with each other. Furthermore, automatic identification of the transmission direction is achieved, avoiding security risks associated with direct user-mode manipulation of hardware channels. This extraction method is logically simple and highly efficient, requiring no traversal of global hardware resources; the target DMA engine can be quickly located using only the session-specific context, effectively reducing kernel processing latency. Simultaneously, it achieves decoupled scheduling of DMA send and receive hardware channels, supporting parallel execution of bidirectional data transmission. This avoids transmission blocking, packet loss, and latency fluctuations caused by send / receive services competing for the same hardware resources, significantly improving the concurrency performance and operational stability of bidirectional DMA data transmission. Moreover, the unified engine matching logic is well-organized and convergent, facilitating subsequent function iterations and troubleshooting.

[0049] Step S230: Send the data transmission request to the Direct Memory Access Engine through a preset submission function so that data can be transmitted through the independent data channel corresponding to the Direct Memory Access Engine.

[0050] In some embodiments, the preset commit function in this application is used to uniformly encapsulate the entire DMA data transmission processing logic. It receives parameters such as data transmission direction, direct memory access engine, user-mode buffer, data transmission length, and offset from the upper-layer read / write callback, and centrally completes the entire process of transmission validity verification, user-mode buffer address conversion, DMA transmission task distribution, and transmission resource reclamation. Both sending and receiving data transmission requests can reuse this preset commit function, distinguishing the transmission direction and corresponding send / receive DMA engine only through input parameters. Ultimately, the transmission task is distributed to the independent hardware data channel bound to the corresponding engine for direct hardware transmission. This eliminates redundant verification, mapping, distribution, and release code, simplifies driver code size, and reduces development and later maintenance costs. Furthermore, the send and receive operations are configured with independent direct memory access engines and independent data channels, ensuring physical isolation of bidirectional transmission resources. A single-direction transmission failure will not interfere with the normal operation of the other direction, further reducing the probability of unidirectional anomaly propagation leading to overall transmission failure, thereby effectively improving data transmission reliability.

[0051] In some embodiments, combined with Figure 3 As shown, Figure 3 yes Figure 2 The flowchart of step S230 in the illustrated embodiment, which implements a data transmission method in an exemplary embodiment, includes at least steps S310 to S330, and is described in detail below: Step S310: Obtain the initial transmission parameters and the Boolean parameter used to indicate the direction of data transmission, and perform an alignment check on the initial transmission parameters, the Boolean parameter, and the direct memory access engine to obtain the alignment check result; wherein, the initial transmission parameters include a single target character device file, a user-mode buffer address, a transmission data length, and a current file offset.

[0052] In this embodiment, the driver receives all transmission parameters passed in by the upper-layer read / write callback, including the single target character device file corresponding to this session, the starting address of the user-mode buffer, the length of the data to be transmitted, and the current file offset. At the same time, it obtains the Boolean parameter representing the transmission direction and the DMA transceiver engine instance matched this time. Combining the hardware constraint specifications of the current DMA engine, it performs a unified hardware alignment legality check on all transmission parameters, outputs the alignment check result, and filters out all illegal requests that do not conform to the hardware transmission specifications.

[0053] In some embodiments, if the Boolean parameter write=1, it indicates that the data transmission direction is from the host memory to the external device, i.e., the sending direction; if the Boolean parameter write=0, it indicates that the data transmission direction is from the external device to the host memory, i.e., the receiving direction.

[0054] For example, the user space initiates a write send request with the boolean parameter write=1. The driver obtains the user-space send buffer address, the length of the data to be sent, and the transmission offset. Combined with the tx_engine send engine hardware parameters extracted from the current context, it verifies whether the address meets 4-byte / 8-byte alignment, whether the transmission length is the smallest granularity supported by the hardware, and whether the offset is valid. If all items are valid, the alignment check result indicates that the check has passed. If issues such as address misalignment or length exceeding limits occur, the alignment check result indicates that the check has failed.

[0055] Step S320: If the alignment check result indicates that all checks have passed, then perform buffer mapping according to the Boolean parameter to obtain a hash table of the physical address information corresponding to the transmission buffer.

[0056] In some embodiments, provided that the initial transfer parameters, Boolean parameters, and alignment checks of the direct memory access engine all pass, the data transfer direction is distinguished according to the Boolean parameters, and address translation and DMA mapping are performed on the user-mode virtual buffer. The user-mode virtual addresses that the CPU cannot directly deliver to the DMA hardware are converted into a set of physical addresses that the DMA hardware can directly address. Finally, a hash table carrying the physical address information of the buffer is generated, which provides legal address resources for hardware DMA transfer.

[0057] In some embodiments, the direct memory access engine includes a send engine and a receive engine, and the transfer buffer includes a send buffer and a receive buffer.

[0058] Combination Figure 4 It can be seen that, Figure 4 yes Figure 3 The flowchart of step S320 in the illustrated embodiment, a method for buffer mapping in an exemplary embodiment, includes at least steps S410 to S420, which are described in detail below: Step S410: If the data transmission direction represented by the Boolean parameter is the sending direction, then perform buffer mapping from the independent memory pool corresponding to the sending engine to obtain a hash table of the physical address information corresponding to the sending buffer.

[0059] For example, the user buffer segments virtual addresses are traversed to complete the virtual address to physical address conversion. Multiple non-contiguous physical address segments are integrated and stored in a hash table. This hash table records all physical fragment information of the transmit buffer and serves as the source address description resource for the DMA transmit channel.

[0060] Step S420: If the data transmission direction represented by the Boolean parameter is the receiving direction, then perform buffer mapping from the independent memory pool corresponding to the receiving engine to obtain a hash table of physical address information corresponding to the receiving buffer.

[0061] For example, the user buffer segments virtual addresses are traversed to complete the virtual address to physical address conversion. Multiple non-contiguous physical address segments are integrated and stored in a hash table. This hash table records all physical fragment information of the receive buffer and serves as the source address description resource for the DMA receive channel.

[0062] In this embodiment, independent DMA engines and corresponding memory pools are used for buffer mapping in the sending and receiving directions, which can effectively avoid transmission resource contention, improve the determinism and parallel processing capability of DMA transmission, and reduce the risk of data corruption.

[0063] In other embodiments, a Boolean parameter `write=1` indicates that the data transmission direction is sending, i.e., from host memory to external device. A Boolean parameter `write=0` indicates that the data transmission direction is receiving, i.e., from external device to host memory.

[0064] Combination Figure 5 As shown, Figure 5 This is a flowchart illustrating a data transmission method in another exemplary embodiment of this application, which includes at least steps S510 to S520, detailed below: Step S510: If the data transmission direction represented by the Boolean parameter is the sending direction, then the sending buffer is released directly after the data transmission is completed, and the data transmission result is returned.

[0065] Step S520: If the data transmission direction represented by the Boolean parameter is the receiving direction, then after the data transmission is completed, copy the data in the receiving buffer to the user-mode buffer, release the receiving buffer, and return the data transmission result.

[0066] In this embodiment, by releasing the send buffer immediately after the DMA transfer is completed in the sending direction and releasing the receive buffer after the data is copied to user space in the receiving direction, a differentiated resource management strategy for different transmission directions is achieved. This avoids long-term occupation of memory resources and ensures the security and integrity of user-space data access.

[0067] Step S330: Call the preset commit function to send a data transfer task carrying boolean parameters, the current file offset, and a hash table to the independent data channel corresponding to the direct memory access engine, so as to perform data transfer through the independent data channel corresponding to the direct memory access engine.

[0068] In this embodiment, by calling a preset DMA commit function, the Boolean parameter representing the transmission direction, the current file offset, and the hash table carrying the physical address information are encapsulated into a DMA transmission task and accurately sent to the independent hardware data channel corresponding to the current DMA engine. The DMA hardware autonomously completes the data transfer between memory and peripherals according to the task configuration, without the CPU participating in data copying, thus realizing direct hardware transfer.

[0069] For example, in the sending scenario, the task is sent to the dedicated DMA channel corresponding to the tx_engine sending engine. The hardware automatically moves the user-space buffer data to the peripheral device based on the hash table source address and offset. In the receiving scenario, the task is sent to the dedicated DMA channel corresponding to the rx_engine receiving engine. The hardware automatically moves the peripheral device data to the mapped user-space buffer. Sending and receiving tasks occupy mutually isolated independent hardware channels, allowing them to execute simultaneously without interference. Furthermore, the sending and receiving channels are independent at the hardware level, so write and read operations can be performed concurrently without the need for software locks.

[0070] In some embodiments, the DMA send engine and the DMA receive engine are each configured with independent locking mechanisms. For example, the DMA send engine and the DMA receive engine are each configured with independent mutex locks to protect the allocation and reclamation of descriptor tables. The DMA send engine and the DMA receive engine are also each configured with independent spinlocks to protect concurrent access to the transfer queue.

[0071] Combination Figure 6 As shown, Figure 6 This is a flowchart illustrating a method for data transmission via a locking mechanism, as shown in an exemplary embodiment of this application. It includes at least steps S610 to S640, detailed below: Step S610: In response to the descriptor allocation request, acquire the mutex lock corresponding to the direct memory access engine; wherein, the mutex locks corresponding to different direct memory access engines are independent of each other.

[0072] It's important to understand that the DMA descriptor table stores DMA hardware transfer task configurations. When multiple processes / threads concurrently initiate transfers, they will simultaneously request free descriptors, posing a risk of concurrency contention. In this solution, the sending engine and receiving engine each have their own dedicated mutex locks, and the two sets of locks are completely isolated and do not interfere with each other. When the upper layer issues a DMA transfer request and needs to allocate hardware descriptors, the driver first acquires the independent mutex lock of the engine corresponding to this transfer, locking the descriptor table operation range and preventing other threads from synchronously operating on the same descriptor table. Send requests only preempt the mutex lock corresponding to the sending engine, and receive requests only preempt the mutex lock corresponding to the receiving engine.

[0073] For example, when multiple user threads simultaneously initiate send requests, requiring the allocation of free file descriptors, the driver only acquires the mutex lock specific to the `tx_engine` send engine. Another thread can synchronously initiate a receive request, acquiring only the mutex lock specific to the `rx_engine` receive engine. Sending and receiving locking operations do not block each other and can be executed in parallel. If two sending threads simultaneously request file descriptors, the later-initiating thread will block and wait for the send mutex lock to be released, preventing concurrent contention for free file descriptors from causing duplicate allocation and data corruption.

[0074] In this embodiment, the transceiver engine uses two independent mutex locks. The sending and receiving descriptor allocation process is lock-free, and bidirectional transmission can be executed concurrently. There will be no performance bottleneck of blocking the sending and receiving business by a single lock. It can accurately isolate the competition for sending and receiving descriptor resources and avoid the increase in transmission latency caused by cross-transmission direction lock conflicts.

[0075] Step S620: When the current thread is in the state of holding a mutex lock, query the preset descriptor table for a free descriptor, mark the free descriptor as occupied, and release the mutex lock after marking.

[0076] In this embodiment, the current thread refers to the thread corresponding to the data transmission request. After the current thread successfully acquires the mutex lock of the corresponding engine, it enters the critical section to operate on the dedicated descriptor table: it traverses and queries for unoccupied free DMA descriptors, modifies the state of the descriptor to occupied, and allocates it to the current transmission task; after completing the state marking, it immediately releases the mutex lock, ends the critical section, and other waiting threads can enter the descriptor allocation process. In this way, the mutex lock protects the descriptor state modification operation, avoids multiple threads simultaneously preempting the same free descriptor, and prevents transmission task configuration overwriting and hardware transmission anomalies.

[0077] Step S630: After the data transmission is completed, in response to the descriptor reclamation request, acquire the mutex lock.

[0078] After data transfer is complete, the driver triggers a descriptor reclamation process, returning used descriptors to the free list. Since reclamation also involves modifying descriptor states, posing a risk of concurrency contention, the driver acquires the independent mutex lock corresponding to the DMA engine before reclamation, thus monopolizing descriptor table operation permissions.

[0079] Step S640: If the current thread is in the state of holding the mutex lock, mark the descriptor that has completed data transfer as unoccupied, and release the mutex lock after marking.

[0080] The current thread, holding the mutex lock, enters the critical section, changes the descriptor's state from "occupied" to "unoccupied," and returns it to the free descriptor pool for allocation by subsequent new transfer tasks. Immediately after the state modification, it releases the mutex lock, allowing other threads to query the free descriptor.

[0081] Combination Figure 7 As shown, Figure 7 This is a flowchart illustrating an exemplary embodiment of the present application of a method for concurrent protection of a transmission queue during data transmission, which includes at least steps S710 to S720, detailed below: Step S710: When it is necessary to modify the transfer queue corresponding to the direct memory access engine, acquire the spinlock corresponding to the direct memory access engine; wherein, the spinlocks corresponding to different direct memory access engines are independent of each other.

[0082] The transmission queue is used to cache DMA task nodes that are pending, in transit, or completed. Kernel threads and hardware interrupt service routines can concurrently add, delete, and modify queue nodes. Interrupt contexts cannot use mutexes that will sleep, so in this embodiment, a spinlock is used to achieve non-blocking concurrency protection.

[0083] In some embodiments, the send DMA engine and the receive DMA engine each have a completely independent set of spinlocks, which are not shared between them. When a program needs to perform operations such as enqueueing, dequeueing, deleting, or clearing the transmission queue, it first acquires the dedicated spinlock of the DMA engine corresponding to the current transmission, exclusively controlling the queue operation rights. This prevents multiple execution flows from simultaneously modifying the queue structure, which could lead to exceptions such as broken linked lists, lost tasks, or infinite loops. In this way, protecting the transmission queue with spinlocks can avoid thread safety issues such as broken linked lists, duplicate task processing, and kernel crashes caused by concurrent modifications from multiple execution flows.

[0084] Step S720: While the current thread is holding a spinlock, modify the transmission queue and release the spinlock after the modification is completed.

[0085] After the current thread / interrupt handler successfully acquires the target engine spinlock, it enters the critical section to perform transmission queue modification operations, including task enqueueing, task dequeueing, invalid task cleanup, and queue node order adjustment. Once all queue node operations are completed, the spinlock is immediately released, allowing other waiting execution flows to access the transmission queue. The spinlock is held only during brief modifications to the linked list, resulting in fast critical section execution. This immediate lock release after modification prevents prolonged occupation of queue resources, ensuring efficient transmission queue scheduling in high-concurrency delivery and recycling scenarios.

[0086] It should be noted that the steps in this embodiment are consistent with the corresponding steps in the foregoing embodiments. Therefore, for a detailed description of these steps, please refer to the description in the foregoing embodiments. This embodiment will not repeat them here.

[0087] Please continue reading. Figures 8 to 12 , Figure 8 This is a schematic diagram illustrating the code implementation for defining a device context, as shown in an exemplary embodiment of this application. Figure 9 This is a schematic diagram illustrating the code implementation of registering a single-target character device file operation set, as shown in an exemplary embodiment of this application. Figure 10 This is a schematic diagram illustrating the code implementation of a write operation in an exemplary embodiment of this application. Figure 11 This is a schematic diagram illustrating the code implementation of a read operation in an exemplary embodiment of this application. Figure 12 This is a schematic diagram illustrating the code implementation of calling a preset commit function, as shown in an exemplary embodiment of this application.

[0088] Figure 8 In this structure, the `tx_engine` transmitting engine and the `rx_engine` receiving engine correspond to two independent sets of DMA channels (or two sets of direction registers in the same hardware unit) on the hardware. They are isolated from each other and have independent data transmission paths and hardware control resources. The software management carrier of the above hardware resources is uniformly encapsulated in the custom kernel device context structure `struct bdma_cdev`. The structure member `tx_engine` is a pointer variable that binds to the transmitting DMA engine instance used for transferring data from host memory to external devices; the structure member `rx_engine` is a pointer variable that binds to the receiving DMA engine instance used for transferring data back from external devices to host memory; `pddev` points to the global instance of the entire BDMA hardware controller, which uniformly manages top-level resources such as hardware base address, global interrupts, and hardware configuration parameters; `cdev` is a standard character device kernel object used to register and generate a unique character device file in the ` / dev` directory, establishing the interaction entry point between user-mode applications and the underlying DMA hardware; the remaining members of the structure also include supporting resources such as mutexes, spinlocks, transfer task queues, DMA memory pools, session state flags, and buffer caches, fully carrying the running state and operation resources required for all DMA transmit and receive services in a single application session.

[0089] By integrating the two independent DMA engine resources for sending and receiving into the same device context structure, user-space applications only need to open a single target character device file and maintain one set of file descriptors to simultaneously schedule the bidirectional DMA hardware channels for sending and receiving, without having to operate two separate device nodes. Furthermore, the hardware resources and software management resources of the sending and receiving engines are isolated one-to-one, allowing for parallel execution of sending and receiving transmissions without preemption of hardware paths and lock resources, effectively improving the concurrent performance of bidirectional data transmission.

[0090] Figure 9 In the `sgdma_h2h_fops` file operation set, `dev_sgdma_h2h_write` is the DMA send operation callback function, and `dev_sgdma_h2h_read` is the DMA receive operation callback function. Both are integrated into the same file operation set, `sgdma_h2h_fops`. This file operation set serves as the sole operation interface and is bound to the standard character device kernel object `structcdev` corresponding to the target character device. The entire operation set only needs to be registered once to provide full-featured file system call support for a single target character device file. The `.write` field binds to the send callback, responding to the user-space `write()` system call to initiate a DMA send transfer from host memory to the peripheral device. The `.read` field binds to the receive callback, responding to the user-space `read()` system call to initiate a DMA receive transfer from the peripheral device to host memory. The operation set also defines common callback functions for device opening, closing, extended control, offset addressing, and memory mapping. The `.open` callback initializes the device context and caches it in the file's private data for quick DMA engine retrieval by read / write callbacks. The `.release` callback releases the resources occupied by the send / receive engine and buffers when the session is closed. User-space applications only need to open a single target character device file, reuse a set of file descriptors, and call the standard read and write interfaces to complete bidirectional DMA data transfer. There is no need to distinguish or open two sets of independent transceiver device nodes, thus achieving unified management of transceiver services through a single interactive entry point.

[0091] Figure 10In this context, dev_sgdma_h2h_write is the write operation callback function corresponding to DMA transmission, which is triggered and executed when a user-space process calls the write() system to access a single target character device file. The function first reads the pre-cached session-specific device context struct bdma_cdev from the private data of the current file structure, and extracts the bound transmission DMA engine tx_engine through the device context; then it calls the unified DMA submission function dev_sgdma_read_write_with_engine, passes in the Boolean parameter 1 identifying the transmission direction and the transmission engine instance, and reuses the general transmission flow to complete the whole process of parameter verification, buffer mapping, DMA task submission and resource recovery. DMA transmission from host memory to an external device can be initiated by relying on the standard write interface provided by a single character device. The transmission and reception logic share the same set of underlying processing functions, and only distinguish the transmission direction and the corresponding hardware engine through input parameters. No additional dedicated transmission device node needs to be configured by the upper-layer application, which simplifies the development logic of two-way transmission services.

[0092] Figure 11 In this context, dev_sgdma_h2h_read is the read operation callback function corresponding to DMA reception, which is triggered and executed when a user-space process calls the read() system call to read and write a single target character device file. The function first reads the private data of the current file, obtains the device context structure struct bdma_cdev corresponding to the current session, and extracts the reception DMA engine rx_engine from the device context; then it calls the general DMA submission function dev_sgdma_read_write_with_engine, passes in the Boolean parameter 0 representing the reception direction and the reception engine instance, and reuses the unified transmission processing link to complete alignment verification, buffer mapping, DMA task submission, resource cleaning and other operations. This read callback and the aforementioned write callback share the same set of underlying DMA processing logic, and only distinguish the transmission direction and the corresponding independent DMA hardware channel through input parameters. User space can complete data reception from a peripheral to host memory only by relying on the standard read interface of a single character device, and there is no need to separately configure an independent reception device node. The unified interaction entry simplifies the two-way transmission development logic of upper-layer applications.

[0093] Figure 12In this embodiment, `dev_sgdma_read_write_with_engine` is the default commit function. It serves as the underlying, general-purpose processing entry point for both DMA send and receive operations, and is jointly called by the read callback function `dev_sgdma_h2h_read` and the write callback function `dev_sgdma_h2h_write`. This function receives multiple input parameters, including the file object, user-space buffer, data length, offset, the boolean parameter `write` representing the transmission direction, and the target DMA engine instance `engine`. It distinguishes between send and receive services based on the `write` parameter and selects the corresponding independent DMA hardware channel based on the `engine` parameter, thus standardizing and completing the entire DMA transfer processing flow.

[0094] For example, the first step involves performing transmission parameter alignment verification based on the incoming DMA engine hardware specifications, intercepting illegal requests whose addresses, lengths, and offsets do not meet the hardware specifications in advance. The second step performs DMA mapping on the user-space virtual buffer according to the transmission direction, converting it into a hardware-recognizable physical address list. The third step issues a DMA transmission task to the independent hardware channel bound to the specified DMA engine, allowing the hardware to autonomously handle the data transfer. The fourth step, regardless of whether the transmission is successful or not, uniformly unmaps the buffer DMA and reclaims kernel resources, forming a complete closed-loop resource lifecycle. The send and receive services reuse this function to complete the core transmission logic, distinguishing the transmission direction and hardware channel only through input parameters, significantly reducing redundant code and achieving a unified interface for transmission logic. This facilitates centralized management of the entire process, including transmission verification, task issuance, and resource reclamation. Simultaneously, it leverages independent send and receive engine parameters to achieve bidirectional hardware channel isolation and concurrent transmission.

[0095] Combination Figure 13 As shown, Figure 13 This is a schematic diagram illustrating the structure of a bidirectional data transmission device based on a single device file, as shown in an exemplary embodiment of this application. Figure 13 As shown, this exemplary bidirectional data transfer device based on a single device file includes: a first acquisition module 1310, a second acquisition module 1320, and a data transfer module 1330; wherein, the first acquisition module 1310 is configured to, in response to a data transfer request from a user-mode application, acquire device context information through a single target character device file, the single target character device file serving as the unique interface between the user-mode application and the direct memory access hardware; the second acquisition module 1320 is configured to extract the direct memory access engine corresponding to the data transfer request from the device context information; the data transfer module 1330 is configured to, through a preset submission function, send the data transfer request to the direct memory access engine for data transfer via the independent data channel corresponding to the direct memory access engine.

[0096] In other embodiments, the direct memory access engine includes a sending engine and a receiving engine. The second acquisition module 1320 is configured to extract the direct memory access engine corresponding to the data transmission request from the device context information in the following ways: if the data transmission request is a sending request, then extract the sending engine from the device context information; if the data transmission request is a receiving request, then extract the receiving engine from the device context information.

[0097] In other embodiments, the data transmission module 1330 is configured to send a data transmission request to the Direct Memory Access Engine (DME) via a preset submission function in the following manner, so as to transmit data through the independent data channel corresponding to the DME: obtaining initial transmission parameters and a Boolean parameter indicating the data transmission direction, and performing an alignment check on the initial transmission parameters, the Boolean parameter, and the DME to obtain an alignment check result; wherein, the initial transmission parameters include a single target character device file, a user-mode buffer address, a transmission data length, and a current file offset; if the alignment check result indicates that all checks have passed, then buffer mapping is performed according to the Boolean parameter to obtain a hash table of physical address information corresponding to the transmission buffer; and the preset submission function is called to send a data transmission task carrying the Boolean parameter, the current file offset, and the hash table to the independent data channel corresponding to the DME, so as to transmit data through the independent data channel corresponding to the DME.

[0098] In other embodiments, the direct memory access engine includes a sending engine and a receiving engine, the transmission buffer includes a sending buffer and a receiving buffer, and the data transmission module 1330 is further configured to perform buffer mapping based on Boolean parameters to obtain a hash table of physical address information corresponding to the transmission buffer, including: if the data transmission direction represented by the Boolean parameter is the sending direction, then performing buffer mapping from the independent memory pool corresponding to the sending engine to obtain a hash table of physical address information corresponding to the sending buffer; if the data transmission direction represented by the Boolean parameter is the receiving direction, then performing buffer mapping from the independent memory pool corresponding to the receiving engine to obtain a hash table of physical address information corresponding to the receiving buffer.

[0099] In other embodiments, the data transmission module 1330 is further configured to: if the data transmission direction represented by the Boolean parameter is the sending direction, then directly release the sending buffer and return the data transmission result after the data transmission is completed; if the data transmission direction represented by the Boolean parameter is the receiving direction, then copy the data in the receiving buffer to the user-mode buffer after the data transmission is completed, then release the receiving buffer and return the data transmission result.

[0100] In other embodiments, the data transmission module 1330 is further configured to acquire a mutex lock corresponding to a direct memory access engine in response to a descriptor allocation request; wherein the mutex locks corresponding to different direct memory access engines are independent of each other; when the current thread is in the state of holding a mutex lock, it queries a free descriptor from a preset descriptor table, marks the free descriptor as occupied, and releases the mutex lock after marking; when the data transmission is completed, it acquires a mutex lock in response to a descriptor reclamation request; when the current thread is in the state of holding a mutex lock, it marks the descriptor that has completed data transmission as unoccupied, and releases the mutex lock after marking.

[0101] In other embodiments, the data transmission module 1330 is further configured to acquire a spinlock corresponding to the direct memory access engine when a modification operation is required on the transmission queue corresponding to the direct memory access engine; wherein the spinlocks corresponding to different direct memory access engines are independent of each other; while the current thread is in the state of holding the spinlock, the modification operation is performed on the transmission queue, and the spinlock is released after the modification operation is completed.

[0102] It should be noted that the bidirectional data transmission device based on a single device file provided in the above embodiments and the bidirectional data transmission method based on a single device file provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the bidirectional data transmission device based on a single device file provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0103] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, enable the electronic device to implement the bidirectional data transmission method based on a single device file provided in the various embodiments above.

[0104] Figure 14 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 14 The computer system 1400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0105] like Figure 14As shown, the computer system 1400 includes a Central Processing Unit (CPU) 1401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1402 or programs loaded from storage portion 1408 into Random Access Memory (RAM) 1403, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1403. The CPU 1401, ROM 1402, and RAM 1403 are interconnected via bus 1404. An Input / Output (I / O) interface 1405 is also connected to bus 1404.

[0106] The following components are connected to I / O interface 1405: an input section 1406 including a keyboard, mouse, etc.; an output section 1407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a model interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1409 performs communication processing via a model such as the Internet. A drive 1410 is also connected to I / O interface 1405 as needed. Removable media 1411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1410 as needed so that computer programs read from them can be installed into storage section 1408 as needed.

[0107] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from the model via communication section 1409, and / or installed from removable medium 1411. When the computer program is executed by central processing unit (CPU) 1401, it performs various functions defined in the system of this application.

[0108] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0109] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the bidirectional data transfer method based on a single device file as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0110] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the bidirectional data transfer method based on a single device file provided in the various embodiments above.

[0111] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

[0112] It is understood that in the specific embodiments of this application, data related to data transmission (such as single target character device files, device context information, etc.) is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A bidirectional data transfer method based on a single device file, characterized in that, include: In response to a data transmission request from a user-mode application, device context information is obtained through a single target character device file. The single target character device file serves as the sole interface between the user-mode application and the direct memory access hardware, enabling the user-mode application to perform send and receive operations. Extracting the direct memory access engine corresponding to the data transmission request from the device context information; wherein, the direct memory access engine includes a sending engine and a receiving engine, and the step of extracting the direct memory access engine corresponding to the data transmission request from the device context information includes: if the data transmission request is a sending request, then extracting the sending engine from the device context information; if the data transmission request is a receiving request, then extracting the receiving engine from the device context information; The data transmission request is sent to the Direct Memory Access Engine via a preset submission function, so that data transmission can be performed through the independent data channel corresponding to the Direct Memory Access Engine.

2. The method according to claim 1, characterized in that, The step of sending the data transmission request to the Direct Memory Access Engine via a preset submission function, so as to transmit data through the independent data channel corresponding to the Direct Memory Access Engine, includes: The initial transmission parameters and a Boolean parameter representing the data transmission direction are obtained, and an alignment check is performed on the initial transmission parameters, the Boolean parameter, and the direct memory access engine to obtain the alignment check result; wherein, the initial transmission parameters include the single target character device file, the user-mode buffer address, the transmission data length, and the current file offset; If the alignment check result indicates that all checks have passed, then buffer mapping is performed according to the Boolean parameter to obtain a hash table of the physical address information corresponding to the transmission buffer; The preset submission function is invoked to send a data transmission task carrying the boolean parameter, the current file offset, and the hash table to the independent data channel corresponding to the direct memory access engine, so as to transmit data through the independent data channel corresponding to the direct memory access engine.

3. The method according to claim 2, characterized in that, The direct memory access engine includes a sending engine and a receiving engine, the transmission buffer includes a sending buffer and a receiving buffer, and the hash table for obtaining the physical address information corresponding to the transmission buffer by mapping the buffer according to the Boolean parameters includes: If the data transmission direction represented by the Boolean parameter is the sending direction, then buffer mapping is performed from the independent memory pool corresponding to the sending engine to obtain a hash table of the physical address information corresponding to the sending buffer; If the data transmission direction represented by the Boolean parameter is the receiving direction, then a buffer mapping is performed from the independent memory pool corresponding to the receiving engine to obtain a hash table of the physical address information corresponding to the receiving buffer.

4. The method according to claim 3, characterized in that, The method further includes: If the data transmission direction represented by the Boolean parameter is the sending direction, then the sending buffer is released directly after the data transmission is completed, and the data transmission result is returned. If the data transmission direction represented by the Boolean parameter is the receiving direction, then after the data transmission is completed, the data in the receiving buffer is copied to the user-mode buffer, the receiving buffer is released, and the data transmission result is returned.

5. The method according to claim 2, characterized in that, The method further includes: In response to a descriptor allocation request, acquire the mutex lock corresponding to the direct memory access engine; wherein, the mutex locks corresponding to different direct memory access engines are independent of each other; When the current thread holds the mutex, a free descriptor is queried from the preset descriptor table, the free descriptor is marked as occupied, and the mutex is released after marking. Once the data transmission is complete, the mutex lock is acquired in response to the descriptor reclamation request; If the current thread holds the mutex, mark the descriptor that has completed data transfer as unoccupied, and then release the mutex.

6. The method according to claim 2, characterized in that, The method further includes: When it is necessary to modify the transfer queue corresponding to the direct memory access engine, the spinlock corresponding to the direct memory access engine is acquired; wherein, the spinlocks corresponding to different direct memory access engines are independent of each other; While the current thread holds the spinlock, it modifies the transmission queue and releases the spinlock after the modification is completed.

7. A bidirectional data transmission device based on a single device file, characterized in that, include: The first acquisition module is configured to acquire device context information through a single target character device file in response to a data transmission request from a user-mode application. The single target character device file serves as the only interface between the user-mode application and the direct memory access hardware. The second acquisition module is configured to extract the direct memory access engine corresponding to the data transmission request from the device context information; wherein the direct memory access engine includes a sending engine and a receiving engine, and the step of extracting the direct memory access engine corresponding to the data transmission request from the device context information includes: if the data transmission request is a sending request, then extracting the sending engine from the device context information; if the data transmission request is a receiving request, then extracting the receiving engine from the device context information. The data transmission module is configured to send the data transmission request to the direct memory access engine through a preset submission function, so as to transmit data through the independent data channel corresponding to the direct memory access engine.

8. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the bidirectional data transfer method based on a single device file as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by the computer's processor, cause the computer to perform the bidirectional data transfer method based on a single device file as described in any one of claims 1 to 6.

Images