CN114003408A - System and method for exchanging messages between kernel mode and user mode - Google Patents

System and method for exchanging messages between kernel mode and user mode Download PDF

Info

Publication number
CN114003408A
CN114003408A CN202111268626.7A CN202111268626A CN114003408A CN 114003408 A CN114003408 A CN 114003408A CN 202111268626 A CN202111268626 A CN 202111268626A CN 114003408 A CN114003408 A CN 114003408A
Authority
CN
China
Prior art keywords
kernel
user
mode
netdev
drv
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111268626.7A
Other languages
Chinese (zh)
Inventor
肖童星
刘小兵
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou DPTech Technologies Co Ltd
Original Assignee
Hangzhou DPTech Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou DPTech Technologies Co Ltd filed Critical Hangzhou DPTech Technologies Co Ltd
Priority to CN202111268626.7A priority Critical patent/CN114003408A/en
Publication of CN114003408A publication Critical patent/CN114003408A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/545Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/543User-generated data transfer, e.g. clipboards, dynamic data exchange [DDE], object linking and embedding [OLE]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/541Client-server

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

The present disclosure relates to a system and method for exchanging messages between a kernel mode and a user mode. The system comprises: the association creation component is used for creating a file operation structure body so as to associate the system calling component with the device driving component, so that the name of each member in the file operation structure body corresponds to a call; the interface creating component is used for creating an exchange interface between the kernel and a user so as to execute the operation of accessing the system kernel data by the user, thereby enabling the kernel space and the user space to carry out information interaction; and the message exchange component is used for starting the exchange interface based on a user instruction, reading a corresponding function pointer in the file operation structure body by executing system call of the file operation structure body so as to transfer the control right to the function, thereby completing the equipment driving.

Description

System and method for exchanging messages between kernel mode and user mode
Technical Field
The present disclosure relates to a method and system for exchanging messages between a kernel mode and a user mode. More particularly, the present disclosure relates to a method and system for exchanging messages between kernel and user states by invoking a system read function module in the kernel state and a system write function module in the user state.
Background
Due to the advancement of technology and the development of market economy, network equipment providers need to continuously improve the portability and stability of products in addition to the performance of equipment in order to further improve the competitiveness of products to meet the demands of markets and customers and to rapidly develop new equipment to be put into the market.
Specifically, in the code level, a program runs in a kernel state or a user state, and thus the portability and the stability of the program are greatly influenced.
When the process running in the kernel mode occupies the CPU, the process can access all data in the memory and control hardware equipment. This means that the kernel-mode program has the highest operating rights. However, the higher the operating rights, the greater the effect and the less stable the system once a defect is present in the program. Moreover, since the kernel mode program can control the hardware, and the hardware of different devices is different, when a new device is developed, the code of the original device needs to be modified greatly to be used on the new device, which undoubtedly prolongs the development cycle of the new device and cannot meet the demands of the market and users in time.
The process running in the user mode has a lower execution right than that in the kernel mode, cannot access all memories and control hardware equipment, and can enter the kernel mode only through system call. However, this also means that user-mode programs are more portable and have a lower probability of fatal defects than kernel-mode programs. Although user mode programs are somewhat less efficient than kernel mode programs, these differences are negligible at the current state of the art hardware devices. Because the program is decoupled from the hardware, the user-mode program has better portability and stability.
Therefore, the most common functional module in the most core of the network device is considered to be operated in the kernel mode, and the other modules are operated in the user mode. In order to complete the related work cooperatively between the modules, a large amount of message data needs to be transmitted between the kernel mode and the user mode.
In order to exchange a large amount of message data between a kernel mode and a user mode, the prior art creates a memory shared by the user mode and the kernel mode, and the memory stores a numerical value. And the user mode program judges whether the kernel mode has data transmission or not by reading the value, and receives the data if the kernel mode has the data transmission. Thus, in the prior art, the user mode program still needs to start a thread and continuously read the values in the shared memory. Although the consumption of reading the memory is less than that of system call, when the kernel mode does not send data, a large amount of invalid operations exist in the system, and CPU resources are occupied.
Therefore, there is a need for a method and system for transferring message data between kernel mode and user mode that does not require a large number of invalid query operations by the user mode program when no message is sent by the kernel mode.
Disclosure of Invention
In order to solve the above-mentioned problems in the prior art, the present disclosure provides a method and system for exchanging messages between a kernel mode and a user mode by calling a system read function module in the kernel mode and calling a system write function module in the user mode.
According to an aspect of the present disclosure, there is provided a system for exchanging messages between a kernel mode and a user mode, the system including: the association creation component is used for creating a file operation structure body so as to associate the system calling component with the device driving component, so that the name of each member in the file operation structure body corresponds to a call; the interface creating component is used for creating an exchange interface between the kernel and a user so as to execute the operation of accessing the system kernel data by the user, thereby enabling the kernel space and the user space to carry out information interaction; and the message exchange component is used for starting the exchange interface based on a user instruction, reading a corresponding function pointer in the file operation structure body by executing system call of the file operation structure body so as to transfer the control right to the function, thereby completing the equipment driving.
According to the system for exchanging messages between the kernel mode and the user mode, the file operation structure is a file _ operations structure, and pointer statements of read and write function modules in the structure are respectively as follows: ssize _ t (, read) (struct file, char __ user, size _ t, loff _ t), ssize _ t (, write) (struct file, const char __ user, size _ t, loff _ t), where the pointer parameter __ user is the buffer in which information is placed.
According to the system for exchanging messages between a kernel state and a user state, disclosed by the invention, the exchange interface is a proc file named as a channel _ net _ dev file, and the structure of the proc file is as follows: proc _ create ("channel _ net _ dev",00777, NULL, & g _ netdev _ fops);
according to the system for exchanging messages between the kernel state and the user state, after the channel _ net _ dev file is opened in the user state, the read function module is called according to the channel _ net _ dev file to transfer data from the kernel space to the user space, and the write function module is called in the user state to transfer data from the user space to the kernel space.
According to the system for exchanging the messages between the kernel mode and the user mode, the write function module calls the copy _ from _ user function module in the kernel mode, so that the user mode data in the buffer area indicated by the pointer parameter __ user is copied to the kernel mode according to the file _ operations structure.
According to the system for exchanging messages between the kernel state and the user state, the channel _ net _ dev file specifies the read-write functions drv _ netdev _ read and drv _ netdev _ write as follows:
const struct file_operationsg_netdev_fops=
{
.owner=THIS_MODULE,
.read=drv_netdev_read,
.write=drv_netdev_write,
.open=drv_netdev_open,
.release=drv_netdev_release,
.unlocked_ioctl=drv_netdev_ioctl,
};
whereby a read function is invoked to call a kernel-state drv _ netdev _ read to transfer data from the kernel space to the user space after the user-state opens the channel _ net _ dev file, and a kernel-state drv _ netdev _ write function module is invoked to transfer data from the user space to the kernel space by calling a write function module.
According to the system for exchanging the messages between the kernel state and the user state, the user _ netdev _ write function module is assigned to the packet sending function port _ start _ xmit of the first virtual port, so that the packet sending function of the first virtual port is called to send the messages from the user state to the kernel state.
According to the system for exchanging messages between the kernel state and the user state, the system further comprises a kernel structure body creating component, which is used for creating a kernel state struct drv _ netdev _ info _ s structure body with the following structure:
struct drv_netdev_info_s
{
struct sk _ buff _ headskb _ list; v. kernel envelope linked list
wait _ queue _ head _ ttx _ wait; v. Send packet wait queue +
};
The kernel structure is used for storing a kernel packet sending linked list skb _ list and a packet sending waiting queue tx _ wait, wherein after the system is started and initialized, a user _ netdev _ hard _ xmit _ thread process is created in a user mode, and the process is used for monitoring whether a kernel sends a packet or not through the kernel packet sending linked list and the packet sending waiting queue information stored in the kernel structure drv _ netdev _ info _ s structure.
According to the system for exchanging the messages between the kernel state and the user state, the user _ netdev _ hard _ xmit _ thread process opens the channel _ net _ dev file in a blocking mode, and repeatedly calls the read function module in a dead loop mode, so that the drv _ netdev _ read function module in the kernel state is called.
According to the system for exchanging the messages between the kernel mode and the user mode, the drv _ netdev _ read function module of the kernel mode adds the current process into the waiting queue tx _ wait each time the drv _ netdev _ read function module of the kernel mode is called.
According to the system for exchanging messages between the kernel mode and the user mode, before the function reading module is called, the process takes out a memory space from a memory pool of the user mode, and transfers the first address pkb of the memory space to drv _ netdev _ read through the second parameter __ user of the read function.
According to the system for exchanging the messages between the kernel mode and the user mode, when the kernel does not send the packet, the process is blocked to execute downwards in the drv _ netdev _ read function module, so that invalid query operation in idle time is avoided.
According to the system for exchanging the messages between the kernel mode and the user mode, when the kernel prepares to send the packet, a socket cache (skb) to be sent is added into a kernel packet sending linked list skb _ list, the process blocked in a waiting queue tx _ wait is awakened so that a drv _ netdev _ read function can be continuously executed downwards, one skb is taken out from the kernel packet sending linked list skb _ list and reassembled into the format of the user mode message, and the newly assembled user mode message is copied into a memory space pointed by pkb through a copy _ to _ user function module so as to finish the data sending.
According to the system for exchanging the messages between the kernel mode and the user mode, the drv _ netdev _ hard _ xmit function module is assigned to the packet sending function hard _ start _ xmit of the second virtual port, and a function prototype of the hard _ start _ xmit is as follows:
int(*hard_start_xmit)(struct sk_buff*skb,struct net_device*dev);
and the sk _ buff is used for sending a structural body of the data packet so as to call the drv _ netdev _ hard _ xmit function module by calling a packet sending function of the second virtual port.
According to another aspect of the present disclosure, there is provided a method for transferring a message from a user mode to a kernel mode in the foregoing system, including the following steps: when data is ready to be sent from a user mode to a kernel mode, calling a user _ netdev _ write function module in the user mode; and after the user _ netdev _ write function opens the channel _ net _ dev file, calling drv _ netdev _ write of the kernel state through the write function, copying the user state data to the kernel state through the imported __ user pointer and copy _ from _ user function, and finishing data transmission.
The message method comprises the following steps: after the system is started and initialized, a process user _ netdev _ hard _ xmit _ thread is created in a user mode, a channel _ net _ dev file created in a kernel mode by a kernel mode file channel _ net _ dev creation module is opened in a blocking mode, a read function is repeatedly called in a dead loop mode, then a kernel-mode drv _ netdev _ read function is called, the drv _ netdev _ read function is entered each time, a current process is added into a waiting queue tx _ wait, so that whether the kernel sends a packet or not is monitored according to a kernel packet sending list skb _ list, wherein before the read function module is called, a program takes out a memory space from a memory pool in the user mode, and an initial address pkb of the memory space is transferred to the drv _ dev _ read _ net through a second parameter __ user of the read function module; when the kernel does not send a packet, the packet is blocked in the drv _ netdev _ read function module and is not executed downwards any more, so that invalid query operation in idle time is avoided; after the kernel prepares to send the packet, the kernel mode program calls a drv _ netdev _ hard _ xmit function module, adds the skb to be sent into a kernel packet sending linked list skb _ list, and awakens the blocked drv _ netdev _ read function in the waiting queue tx _ wait so as to continuously execute the function; and a skb is taken out from the kernel packet sending linked list skb _ list, and is reassembled into the format of the user mode message, and the newly assembled user mode message is copied into the memory space pointed by pkb through a copy _ to _ user function, so that the data sending is completed.
According to the technical scheme, the method and the system are mainly used for efficiently transmitting the message data between the kernel mode and the user mode, when the kernel does not send the message, the user mode packet receiving process is blocked, a large amount of invalid query operations are avoided, CPU occupation is reduced, the implementation is relatively easy, and the reliability is high.
Drawings
The disclosure may be better understood by describing exemplary embodiments thereof in conjunction with the following drawings, in which:
FIG. 1 illustrates a system for exchanging messages between a kernel mode and a user mode according to one embodiment of the disclosure;
FIG. 2 illustrates a flow diagram of a method of transferring a message from a user state to a kernel state in a system exchanging messages between the kernel state and the user state according to one embodiment of the disclosure; and
fig. 3 shows a flow diagram of a method of transferring a message from a kernel mode to a user mode in a system exchanging messages between the kernel mode and the user mode according to one embodiment of the present disclosure.
Detailed Description
In the following description of the embodiments of the present disclosure, it is noted that in the interest of brevity and conciseness, not all features of an actual implementation may be described in detail in this specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions are made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be further appreciated that such a development effort might be complex and tedious, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure, and it will be appreciated that such a development effort might be complex and tedious.
Unless otherwise defined, technical or scientific terms used in the claims and the specification should have the ordinary meaning as understood by those of ordinary skill in the art to which this disclosure belongs. The use of "first," "second," and similar terms in the description and claims of the present disclosure are not intended to indicate any order, quantity, or importance, but rather are used to distinguish one element from another. The terms "a" or "an," and the like, do not denote a limitation of quantity, but rather denote the presence of at least one. The word "comprising" or "comprises", and the like, means that the element or item appearing before "comprises" or "comprising" covers the element or item listed after "comprising" or "comprises" and its equivalent, and does not exclude other elements or items.
According to the embodiment of the disclosure, in the Linux operating system, when a process executes a system call and enters kernel code for execution, the process is called to be in a kernel running state or a kernel state for short.
According to the embodiment of the disclosure, in the Linux operating system, a process is called in a user state when executing its own code (a function such as a non-system call).
According to an embodiment of the present disclosure, the Proc File System is a special software-created File System that interfaces operations that access system kernel data in a file system fashion. This file system enables information interaction between kernel space and user space.
According to an embodiment of the present disclosure, a socket buffer (skb) is a Linux network core data structure, which represents a packet to be sent or processed, and runs through the entire protocol stack.
The Linux operating system associates system calls with drivers using a file operations structure, the name of each member of which corresponds to a call. The corresponding function pointer in the file _ operation (such as read or write function module) is read, and then the control right is transferred to the function module, thereby completing the work of the Linux device driver.
Referring to fig. 1, a system for exchanging messages between a kernel mode and a user mode is shown according to one embodiment of the present disclosure. A system for exchanging messages between a kernel mode and a user mode, the system comprising: an association creation component 10 for creating a file operation structure 110 for associating the system call component with the device driver component such that the name of each member in the file operation structure corresponds to a call; the interface creating component 20 is used for creating an exchange interface 120 between the kernel and the user so as to execute the operation of accessing the system kernel data by the user, thereby enabling the kernel space and the user space to carry out information interaction; and the message exchange component 40 is used for starting the exchange interface based on a user instruction, reading a corresponding function pointer in the file operation structure body by executing system call of the file operation structure body so as to transfer the control right to the function, thereby completing the device driving.
The file operation structure 110 is a file _ operations structure 110, and pointer statements of read and write function modules in the structure are respectively: ssize _ t (, read) (struct file, char __ user, size _ t, loff _ t), ssize _ t (, write) (struct file, const char __ user, size _ t, loff _ t), where the pointer parameter __ user is the buffer in which information is placed. In the following description, the flag 110 may be used if both the file operations structure and the file operations structure are referred to.
The exchange interface 120 is a proc file named as channel _ net _ dev file 120, and its structure is: proc _ create ("channel _ net _ dev",00777, NULL, & g _ netdev _ fops); after the channel _ net _ dev file is opened in the user mode, a read function module is called according to the channel _ net _ dev file to transfer data from the kernel space to the user space, and a write function module is called in the user mode to transfer data from the user space to the kernel space. In the following description, the tag 120 may be used if it is mentioned that both the fchannel _ net _ dev file and the swap interface.
The system further comprises a kernel structure creation component 30 for creating a kernel structure, also referred to as kernel state struct drv _ netdev _ info _ s structure 130. In the following description, the tag 100 may be used if referring to both the state struct drv _ netdev _ info _ s structure and the kernel structure.
The system is part of a Linux operating system, and comprises a file _ operations structure 110, a channel _ net _ dev file 120 and a struct drv _ netdev _ info _ s structure 130, as shown in fig. 1. These constructs or files are consistent with the same name constructs or files in the Linux operating system and are therefore not described in detail herein. Only those portions of these structures or documents relevant to the present disclosure are referred to below.
The pointers to the read and write function modules in the file operations structure 110 are declared as follows:
ssize_t(*read)(struct file*,char__user*,size_t,loff_t*);
ssize_t(*write)(struct file*,const char__user*,size_t,loff_t*);
the pointer parameter __ user is here a buffer for placing information, i.e., a user space memory address. Some data ready to be passed to the kernel may be written __ user directed to the memory space. Then, the program (or process) calls a copy _ from _ user function module (functions not specifically defined here and below, which are kernel functions of the Linux operating system) in the kernel mode to copy the user-mode data in the buffer indicated by the pointer parameter __ user to the kernel mode according to the file _ operations structure.
The channel _ net _ dev file is a proc file having the following structure:
proc_create("channel_net_dev",00777,NULL,&g_netdev_fops);
the important point specifies the read-write functions drv _ netdev _ read and drv _ netdev _ write of the channel _ net _ dev file. The method comprises the following specific steps:
const struct file_operationsg_netdev_fops=
{
.owner=THIS_MODULE,
.read=drv_netdev_read,
.write=drv_netdev_write,
.open=drv_netdev_open,
.release=drv_netdev_release,
.unlocked_ioctl=drv_netdev_ioctl,
};
through the specification, after the program opens the channel _ net _ dev file in the user mode, the program calls the read function module to call drv _ netdev _ read in the kernel mode, and data are transmitted to the user space from the kernel space; and the program calls the write function module in the user mode to call the drv _ netdev _ write function module in the kernel mode, so that the data is transferred from the user space to the kernel space.
Therefore, the information interaction between the kernel mode and the user can be completed by taking the channel _ net _ dev file as an intermediary.
According to an embodiment of the present disclosure, the user _ netdev _ write function module may also be implemented with a virtual port. By defining the virtual port in the user mode, the process of sending the message from the user mode to the kernel mode is abstracted into the process of sending the data packet by the virtual port.
Specifically, a virtual port is defined in the user state, named veth0_2, and its encapsulating function port _ start _ xmit (similar to hard _ start _ xmit, also a function pointer) is assigned to the user _ netdev _ write function module.
Therefore, the user _ netdev _ write function can be called only by calling the packet sending function of the port veth0_2, and the message is sent from the user mode to the kernel mode.
The kernel state struct drv _ netdev _ info _ s structure 130 is defined as:
struct drv_netdev_info_s
{
struct sk _ buff _ headskb _ list; v. kernel envelope linked list
wait _ queue _ head _ ttx _ wait; v. Send packet wait queue +
};
The structure is used for storing a kernel packet sending linked list skb _ list and a packet sending waiting queue tx _ wait.
After the system is started and initialized, a process user _ netdev _ hard _ xmit _ thread is created in a user mode, and the process is used for monitoring whether a kernel sends a packet or not through a kernel packet sending linked list and packet sending waiting queue information stored in a kernel mode struct drv _ netdev _ info _ s structure 130, for example, when the kernel packet sending linked list skb _ list is empty, it is determined that the process does not have a packet waiting to be sent.
The process user _ netdev _ hard _ xmit _ thread opens a channel _ net _ dev file in a blocking mode, and repeatedly calls a read function module in a dead loop mode, so that a kernel-state drv _ netdev _ read function module is called. And each time the drv _ netdev _ read function module is entered, adding the current process into the waiting queue tx _ wait.
In addition, before calling the read function, the program fetches a block of memory space from a memory pool in the user mode and passes the first address pkb of the memory space to drv _ netdev _ read via the second parameter __ user of the read function.
When the kernel does not send a packet (i.e. the kernel packet sending linked list skb _ list is empty), the program will block in the drv _ netdev _ read function (__ set _ current _ state (TASK _ interrupt) and schedule () are executed), and no further execution is performed, so that a large amount of invalid query operations in idle time are avoided.
And after the kernel prepares to send the packet, calling a drv _ netdev _ hard _ xmit function by the kernel mode program, and adding the skb to be sent into a kernel packet sending linked list skb _ list. The function then wakes up the process waiting for the block in the queue tx _ wait. And continuously executing the awakened drv _ netdev _ read function downwards, taking out one skb from the kernel packet sending chain table skb _ list, reassembling the skb into a user mode message format, and copying the newly assembled user mode message into the memory space pointed by pkb through the copy _ to _ user function module to finish the data sending.
According to an embodiment of the present disclosure, the drv _ netdev _ hard _ xmit function module may also be implemented with a virtual port. By defining the virtual port in the kernel mode, the process of sending messages from the kernel mode to the user mode is abstracted into the process of sending data packets by the virtual port.
Specifically, in the Linux system, network devices are abstracted as a struct net _ device structure, and each network device has a unique device name.
A virtual port is defined in a kernel mode, named ieth0_1, and a packet sending function hard _ start _ xmit (which is a function pointer defined in the struct net _ device structure) is assigned as a drv _ netdev _ hard _ xmit function module.
The functional prototype of hard _ start _ xmit is as follows:
int(*hard_start_xmit)(struct sk_buff*skb,struct net_device*dev);
where sk _ buff is the structure used to send the packet. Therefore, the drv _ netdev _ hard _ xmit function module can be called only by calling the packet sending function of the port ieth0_1, and the message is sent from the kernel mode to the user mode.
Fig. 2 shows a flow diagram of a method of transferring a message from a user mode to a kernel mode in a system exchanging messages between the kernel mode and the user mode according to one embodiment of the present disclosure. When there is data to be sent from the user mode to the kernel mode, the user mode program calls the user _ netdev _ write function module. After the function module opens a channel _ net _ dev file, the write function module calls drv _ netdev _ write of the kernel state, user state data is copied to the kernel state through an incoming __ user pointer and a copy _ from _ user function, and data sending is completed.
Fig. 3 shows a flow diagram of a method of transferring a message from a kernel mode to a user mode in a system exchanging messages between the kernel mode and the user mode according to one embodiment of the present disclosure. After the system starts and completes initialization, the program creates a process user _ netdev _ hard _ xmit _ thread in the user mode. The process opens a channel _ net _ dev file in a blocking mode, repeatedly calls a read function module in a dead loop mode, and further calls a kernel-mode drv _ netdev _ read function module. Each time the drv _ netdev _ read function module is entered, the current process is added to the wait queue tx _ wait.
In addition, before calling the read function module, the program will fetch a block of memory space from a memory pool in the user mode and pass the first address pkb of the memory space to drv _ netdev _ read through the second parameter __ user of the read function module.
When the kernel does not send a packet (i.e. the kernel packet sending linked list skb _ list is empty), the program will block in the drv _ netdev _ read function (__ set _ current _ state (TASK _ interrupt) and schedule () are executed), and no further execution is performed, so that a large amount of invalid query operations in idle time are avoided.
And after the kernel prepares to send the packet, calling a drv _ netdev _ hard _ xmit function by the kernel mode program, and adding the skb to be sent into a kernel packet sending linked list skb _ list. The function then wakes up the process waiting for the block in the queue tx _ wait. And continuously executing the awakened drv _ netdev _ read function downwards, taking out one skb from the kernel packet sending linked list skb _ list, reassembling the skb into a user mode message format, and copying the newly assembled user mode message into the memory space pointed by pkb through the copy _ to _ user function to finish the data sending.
According to the technical scheme, the method and the system are mainly used for efficiently transmitting the message data between the kernel mode and the user mode, when the kernel does not send the message, the user mode packet receiving process is blocked, a large amount of invalid query operations are avoided, CPU occupation is reduced, the implementation is relatively easy, and the reliability is high.
The basic principles of the present disclosure have been described above in connection with specific embodiments, but it should be noted that it will be understood by those skilled in the art that all or any of the steps or components of the method and system of the present disclosure may be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof, which can be implemented by those skilled in the art using their basic programming skills after reading the description of the present disclosure.
Thus, the objects of the present disclosure may also be achieved by running a program or a set of programs on any computing device. The computing device may be a general purpose device as is well known. Thus, the objects of the present disclosure may also be achieved solely by providing a program product comprising program code for implementing the method or system. That is, such a program product also constitutes the present disclosure, and a storage medium storing such a program product also constitutes the present disclosure. It is to be understood that the storage medium may be any known storage medium or any storage medium developed in the future.
It is also noted that, in the systems and methods of the present disclosure, it is apparent that individual components or steps may be disassembled and/or recombined. These decompositions and/or recombinations are to be considered equivalents of the present disclosure. Also, the steps of executing the series of processes described above may naturally be executed chronologically in the order described, but need not necessarily be executed chronologically. Some steps may be performed in parallel or independently of each other.
The above detailed description should not be construed as limiting the scope of the disclosure. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims (16)

1. A system for exchanging messages between a kernel mode and a user mode, the system comprising:
the association creation component is used for creating a file operation structure body so as to associate the system calling component with the device driving component, so that the name of each member in the file operation structure body corresponds to a call;
the interface creating component is used for creating an exchange interface between the kernel and a user so as to execute the operation of accessing the system kernel data by the user, thereby enabling the kernel space and the user space to carry out information interaction;
and the message exchange component is used for starting the exchange interface based on a user instruction, reading a corresponding function pointer in the file operation structure body by executing system call of the file operation structure body so as to transfer the control right to the function, thereby completing the equipment driving.
2. The system of claim 1, wherein the file operation structure is a file operations structure, and pointer declarations of read and write function modules in the structure are respectively:
ssize_t(*read)(struct file*,char__user*,size_t,loff_t*);
ssize_t(*write)(struct file*,const char__user*,size_t,loff_t*);
where the pointer parameter __ user is a buffer to place information.
3. The system of claim 2, wherein the exchange interface is a proc file named channel _ net _ dev file, and is structured as:
proc_create("channel_net_dev",00777,NULL,&g_netdev_fops)。
4. a system as in claim 3, wherein after the channel _ net _ dev file is opened in the user mode, a read function module is invoked to pass data from the kernel space to the user space according to the channel _ net _ dev file, and a write function module is invoked to pass data from the user space to the kernel space in the user mode.
5. The system of claim 3, wherein the write function module invokes a copy from user function module in kernel mode to copy user-state data in the buffer indicated by the pointer parameter __ user to kernel mode according to a file operations structure.
6. The system of claim 3, wherein the channel _ net _ dev file specifies the read-write functions drv _ netdev _ read and drv _ netdev _ write as follows:
Figure FDA0003327857350000011
Figure FDA0003327857350000021
whereby a read function is invoked to call a kernel-state drv _ netdev _ read to transfer data from the kernel space to the user space after the user-state opens the channel _ net _ dev file, and a kernel-state drv _ netdev _ write function module is invoked to transfer data from the user space to the kernel space by calling a write function module.
7. The system of claim 6, wherein the user _ netdev _ write function module is assigned to the first virtual port's send out function port _ start _ xmit, so that the first virtual port's send out function is called to send the message from user state to kernel state.
8. The system of claim 3, further comprising a kernel structure creation component to create a kernel state struct drv _ netdev _ info _ s structure of the structure:
Figure FDA0003327857350000022
the kernel node structure body is used for storing a kernel packet sending linked list skb _ list and a packet sending waiting queue tx _ wait,
after the system is started and initialized, a user _ netdev _ hard _ xmit _ thread process is created in a user mode, and the process is used for monitoring whether a kernel sends a packet or not through a kernel package sending chain table and package sending waiting queue information which are stored in a kernel mode struct drv _ netdev _ info _ s structure.
9. The system of claim 8, wherein the user _ netdev _ hard _ xmit _ thread process opens a channel _ net _ dev file in a blocking manner and repeatedly calls the read function module in a dead loop manner, thereby calling the kernel-state drv _ netdev _ read function module.
10. The system of claim 9, wherein the kernel-mode drv _ netdev _ read function module adds the current process to the wait queue tx _ wait each time it is called.
11. The system of claim 9, wherein prior to calling the read function module, the process fetches a block of memory space from a memory pool in the user state and passes the first address pkb of the memory space to drv _ netdev _ read via the second parameter __ user of the read function.
12. The system of claim 9, wherein when the kernel is not sending packets, the process blocks down execution in the drv _ netdev _ read function module to avoid invalid query operations when idle.
13. The system of claim 9, wherein when the kernel prepares to send a packet, the socket cache (skb) to be sent is added to the kernel packet sending chain skb _ list, and wakes up the process blocked in the waiting queue tx _ wait to make the drv _ netdev _ read function continue to execute downwards, takes out one skb from the kernel packet sending chain skb _ list, and reassembles into the format of the user-mode message, and copies the newly assembled user-mode message to the memory space pointed by pkb through the copy _ to _ user function module to complete the data sending.
14. The system of claim 13, wherein the drv _ netdev _ hard _ xmit function module is assigned to the packetization function hard _ start _ xmit of the second virtual port, the function prototype of hard _ start _ xmit being as follows:
int(*hard_start_xmit)(struct sk_buff*skb,struct net_device*dev);
and the sk _ buff is used for sending a structural body of the data packet so as to call the drv _ netdev _ hard _ xmit function module by calling a packet sending function of the second virtual port.
15. A method for transferring a message from a user mode to a kernel mode in a system according to any one of claims 1 to 14, comprising the steps of:
when data is ready to be sent from a user mode to a kernel mode, calling a user _ netdev _ write function module in the user mode; and
after the user _ netdev _ write function opens the channel _ net _ dev file, the write function calls the drv _ netdev _ write in the kernel state, and the user state data is copied to the kernel state through the imported __ user pointer and the copy _ from _ user function, so that data transmission is completed.
16. A method of transferring a message from a kernel mode to a user mode in a system according to any one of claims 1 to 14, comprising the steps of:
after the system is started and initialized, a process user _ netdev _ hard _ xmit _ thread is created in a user mode, a channel _ net _ dev file created in a kernel mode by a kernel mode file channel _ net _ dev creation module is opened in a blocking mode, a read function is repeatedly called in a dead loop mode, then a kernel-mode drv _ netdev _ read function is called, the drv _ netdev _ read function is entered each time, a current process is added into a waiting queue tx _ wait, so that whether the kernel sends a packet or not is monitored according to a kernel packet sending list skb _ list, wherein before the read function module is called, a program takes out a memory space from a memory pool in the user mode, and an initial address pkb of the memory space is transferred to the drv _ dev _ read _ net through a second parameter __ user of the read function module;
when the kernel does not send a packet, the packet is blocked in the drv _ netdev _ read function module and is not executed downwards any more, so that invalid query operation in idle time is avoided; while
After the kernel prepares to send a packet, the kernel mode program calls a drv _ netdev _ hard _ xmit function module, adds skb to be sent into a kernel packet sending linked list skb _ list, and awakens a drv _ netdev _ read function blocked in a waiting queue tx _ wait so as to continuously execute the function; and is
And taking out one skb from the kernel packet sending linked list skb _ list, reassembling the skb into a format of the user mode message, and copying the newly assembled user mode message into the memory space pointed by pkb through a copy _ to _ user function so as to finish the data sending.
CN202111268626.7A 2021-10-29 2021-10-29 System and method for exchanging messages between kernel mode and user mode Pending CN114003408A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111268626.7A CN114003408A (en) 2021-10-29 2021-10-29 System and method for exchanging messages between kernel mode and user mode

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111268626.7A CN114003408A (en) 2021-10-29 2021-10-29 System and method for exchanging messages between kernel mode and user mode

Publications (1)

Publication Number Publication Date
CN114003408A true CN114003408A (en) 2022-02-01

Family

ID=79924931

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111268626.7A Pending CN114003408A (en) 2021-10-29 2021-10-29 System and method for exchanging messages between kernel mode and user mode

Country Status (1)

Country Link
CN (1) CN114003408A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115840938A (en) * 2023-02-21 2023-03-24 山东捷讯通信技术有限公司 File monitoring method and device

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110270944A1 (en) * 2010-04-27 2011-11-03 Tixel Gmbh Networking system call data division for zero copy operations
CN104102494A (en) * 2014-07-31 2014-10-15 武汉邮电科学研究院 Air interface data cipher acceleration method of wireless communication base station

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110270944A1 (en) * 2010-04-27 2011-11-03 Tixel Gmbh Networking system call data division for zero copy operations
CN104102494A (en) * 2014-07-31 2014-10-15 武汉邮电科学研究院 Air interface data cipher acceleration method of wireless communication base station

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KYLE C. HALE等: "An Evaluation of Asynchronous Software Events on Modern Hardware", 《2018 IEEE 26TH INTERNATIONAL SYMPOSIUM ON MODELING, ANALYSIS, AND SIMULATION OF COMPUTER AND TELECOMMUNICATION SYSTEMS (MASCOTS)》, 8 November 2018 (2018-11-08), pages 355 - 368 *
赵昕等: "LINUX系统下GPIB驱动优化设计与实现", 《计算机测量与控制》, 25 March 2020 (2020-03-25), pages 163 - 167 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115840938A (en) * 2023-02-21 2023-03-24 山东捷讯通信技术有限公司 File monitoring method and device

Similar Documents

Publication Publication Date Title
US5560029A (en) Data processing system with synchronization coprocessor for multiple threads
US7650605B2 (en) Method and apparatus for implementing atomicity of memory operations in dynamic multi-streaming processors
US8972699B2 (en) Multicore interface with dynamic task management capability and task loading and offloading method thereof
US20150277993A1 (en) Task Processing Method and Virtual Machine
US8028298B2 (en) Systems and methods for managing shared resources in a computer system
CN112306669A (en) Task processing method and device based on multi-core system
US7418714B2 (en) Employing three parameter buffer access in connection with SMBus notifications
CN110874336B (en) Distributed block storage low-delay control method and system based on Shenwei platform
EP1760580A1 (en) Processing operation information transfer control system and method
WO2021113007A1 (en) Apparatus and methods for virtualization
CN114003408A (en) System and method for exchanging messages between kernel mode and user mode
CN112506676B (en) Inter-process data transmission method, computer device and storage medium
US8732441B2 (en) Multiprocessing system
CN100349121C (en) Embedded type parallel computation system and embedded type parallel computing method
EP1299801B1 (en) Method and apparatus for implementing atomicity of memory operations in dynamic multi-streaming processors
US9946665B2 (en) Fetch less instruction processing (FLIP) computer architecture for central processing units (CPU)
CN116360941A (en) Multi-core DSP-oriented parallel computing resource organization scheduling method and system
Giloi Parallel supercomputer architectures and their programming models
Tanenbaum A comparison of three microkernels
US7043565B1 (en) System and method for transferring data over an external transmission medium
US7320044B1 (en) System, method, and computer program product for interrupt scheduling in processing communication
Leslie et al. Encapsulated user-level device drivers in the Mungi operating system
US20090019159A1 (en) Transparently externalizing plug-in computation to cluster
Gupta et al. Operating system
Ostheimer Parallel Functional Computation on STAR: DUST—

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination