Method and device for realizing large-scale precise timer on user mode level based on Linux

Abstract

The invention provides a method and a device for realizing a large-scale precise timer on a user mode level based on Linux, and the method comprises the steps: defining an ioctl command protocol between a user and a driver, constructing an arg parameter from a timer parameter and user process information through the calling of an ioctl system, and transmitting the arg parameter to a kernel driver module; the kernel driving module identifies and processes commands and parameters transmitted by the ioctl, calls a kernel timer module, defines a timeout callback processing function at the same time, and inserts parameter information called by the API into a driving module linked list after the API is operated; the kernel timer module puts the timer resource started this time into a timer resource table managed by the kernel, periodically checks whether a timeout timer exists or not, and when it is checked that the timeout timer exists in the current time slot, the brought-in arg parameters are returned to a timeout callback processing function together; and the kernel driving module identifies user process information according to the returned arg parameter, a signal is sent from the kernel to the user state process, and the user process completes timeout positioning after receiving the signal.

Description

Technical Field

[0001] The embodiments of the present invention generally relate to the field of computer technology, and more particularly to a method and device for implementing a large-scale accurate timer at a user level based on Linux. Background Art

[0002] There are two main timer methods provided by Linux to applications. One is to process the SIGALRM signal by registering and setting the timeout period through the alarm() system call. After the timeout, the kernel sends the SIGALRM signal to the application, and the callback notifies the application of the timeout event. The other is to use the setitimer() system call, which can be used in conjunction with the three Linux signals SIGALRM, SIGVTALRM, and SIGPROF to trigger the Linux timeout callback respectively. The application will also receive the signal triggered by the Linux kernel after the timeout, and the timeout event can be identified by registering the signal processing function.

[0003] The common point of these two methods is that they both enable user-mode applications to use accurate timers by registering a callback function for a Linux signal and processing the timeout signal returned from the kernel mode. However, their limitation is that an application process can only register and use a specific system signal once, and can only be triggered again after the timeout callback is completed. That is, this method cannot meet the communication protocol's requirement of triggering a large number of timers at the same time for concurrent processing of a large number of communication connections. For user-level applications to be able to cope with the scenario of concurrent processing of a large number of timers, a simple solution is to maintain the timing function in the user space by imitating the logic of the Linux timer within the application. Although this can support large-scale timer maintenance, it is subject to the scheduling overhead of the operating system for applications running in user mode. This method cannot guarantee the accurate timing of the timer. Once the CPU is busy, timing deviations will occur. Summary of the invention

[0004] To solve the above problems, the present invention directly calls the Linux kernel timer in the kernel state by loading the kernel driver module in the application under the Linux platform, and then the application controls the kernel driver through the ioctl() system call to realize the timer start and stop operation and the transmission of timer parameters, thereby meeting the requirements of large-scale timers being able to be concurrent in the user state to start different timers in multiple connections and multiple states in the communication protocol and to be able to accurately time.

[0005] According to an embodiment of the present invention, a method and device for implementing a large-scale accurate timer at a user level based on Linux are provided.

[0006] In a first aspect of the present invention, a method for implementing a large-scale accurate timer at the user level based on Linux is provided. The method comprises:

[0007] S01: define the ioctl command protocol between the user and the driver. The user-mode process constructs the arg parameter with the timer parameter and the user process information through the ioctl system call and passes it to the kernel driver module.

[0008] S02: The kernel driver module identifies and processes the commands and parameters passed in by ioctl, and uses the API add_timer(struct timer_list*) provided by the Linux timer library to call the kernel timer module. The kernel driver module writes the received arg into the structure timer_list provided by the kernel timer module, and at the same time, the kernel driver module defines a timeout callback processing function and passes the function into the timer_list structure; after running the API, the kernel driver module inserts the structtimer_list* parameter information called by the API into the driver module linked list;

[0009] S03: The kernel timer module puts the timer resource started this time into the timer resource table managed by the kernel. The kernel timer module will periodically check whether there is a timer that has timed out in each clock. When it is detected that there is a timer that has timed out in the current time slot, it triggers the timeout callback processing function passed in when the add_timer() API is started, and returns the arg parameter brought in to the timeout callback processing function;

[0010] S04: The kernel driver module identifies the user process information according to the arg parameter returned by the timeout callback processing function, sends a signal from the kernel to the user process, and returns it with the arg parameter. After receiving the signal, the user process parses arg to complete the timeout positioning.

[0011] Further, the content of the ioctl command protocol between the user and the driver described in S01 is: define the start timer command START_CMD (_IOW (0XEF, 0X2, unsigned long)) and the close timer command STOP_CMD (_IOW (0XEF, 0X1, unsigned long)), where 0XEF is used to specify the command type, 0X1 and 0X2 specify the command ID, and unsigned long refers to the parameter type that ioctl can carry;

[0012] Unsigned long is filled in the following format: 2 bytes of internal resource index, 1 byte of index type, 1 byte of TimerId and 1 byte of Pid, ​​where Pid is filled with the process number of the application and is sent to the correct process when the kernel driver callback is made; TimerId is filled with specific timer types according to the needs of different applications, which uniquely corresponds to a timer. Through this value, the kernel driver module corresponds to a predetermined timeout period; the internal resource index is used to mark the connection or session that started the TimerId. When the timer times out, the application can correspond to the accurate session; the index type is used to distinguish the internal resource type corresponding to the value of the resource index.

[0013] Furthermore, the design logic of the kernel driver module described in S01 is:

[0014] S011: Initialization work: Use MKDEV to create a timer device description and register the device, initialize the operation set of the timer device, and create the timer device;

[0015] Predefined SIG_TMR signal;

[0016] Define the timer timeout processing function and set the timeout time corresponding to different timer types according to the specific application agreed rules to generate a TimerId-timeout mapping array;

[0017] Establish a driver module linked list for storing each timer request parameter;

[0018] Register the response function of the ioctl start timer command START_CMD and the close timer command STOP_CMD:

[0019] Among them, the response function logic of the start timer command START_CMD is: extract the arg parameter of the ioctl system call, read out the TimerId and obtain the timeout time of the timer according to the mapping array of TimerId-timeout time, construct the kernel timer structure struct timer_list, fill in the timeout time, timeout callback function and arg parameter according to the structure of timer_list, then call the add_timer() interface provided by the Linux kernel to start a kernel timer, and store the timer_list structure in the driver module linked list;

[0020] The response function logic of the shutdown timer command STOP_CMD is as follows: extract the arg parameter of the ioctl system call, find the timer_list structure corresponding to the arg parameter from the driver module list, call the system API del_timer() to delete the timer, and clear the corresponding information in the driver module list;

[0021] S012: When the application calls ioctl to the kernel driver module, the kernel driver's ioctl processing function identifies the command parameters. If a start timer command is received, the arg parameter is parsed, the TimerId is obtained and the timeout time is found. The timeout time, the timeout callback function and the arg parameter are filled into the timer_list structure required to start the kernel timer, and add_timer() is called to start the kernel timer and update the driver module linked list. If a stop timer command is received, the driver module linked list is searched according to the arg parameter, del_timer() is called to stop the kernel timer, and the resources in the driver module linked list are deleted.

[0022] S013: When the timer times out, the kernel timer module calls the timeout callback processing function and passes the arg parameter passed in when starting the timer back to the timeout callback processing function that starts the timer module. The kernel driver module obtains the Pid of the user process by parsing arg, sends a SIG_TMR signal to the process corresponding to the Pid and returns it to the user process with the arg parameter, and deletes the node that exists in the driver module linked list when the timer is started.

[0023] Furthermore, the workflow of the user state process is as follows:

[0024] Register a device file / dev / timer dedicated to the timer and obtain the file descriptor fd;

[0025] Register a function signal_handler() to handle kernel driver callback events;

[0026] Record the Pid of this process as part of the ioctl command parameters, and send the ioctl system call to the kernel driver module with different parameters.

[0027] In a second aspect of the present invention, a device for implementing a large-scale accurate timer at the user level based on Linux is provided. The device comprises:

[0028] Protocol definition module: used to define the ioctl command protocol between the user and the driver. The user-mode process constructs the arg parameter of the timer parameter and the user process information and passes it to the kernel driver module through the ioctl system call.

[0029] Command processing module: used by the kernel driver module to identify and process the commands and parameters passed in by ioctl, and use the API add_timer(struct timer_list*) provided by the Linux timer library to call the kernel timer module. The kernel driver module writes the received arg into the structure timer_list provided by the kernel timer module. At the same time, the kernel driver module defines the timeout callback processing function and passes the function into the timer_list structure. After running the API, the kernel driver module inserts the struct timer_list* parameter information called by the API into the driver module linked list;

[0030] Timeout check module: used by the kernel timer module to put the timer resources started this time into the timer resource table managed by the kernel. The kernel timer module will periodically check whether there is a timeout timer in each clock. When it is detected that there is a timeout timer in the current time slot, it will trigger the timeout callback processing function passed in when starting through the add_timer() API, and return the arg parameter brought in to the timeout callback processing function;

[0031] Timeout positioning module: used by the kernel driver module to identify the user process information according to the arg parameter returned by the timeout callback processing function, send a signal from the kernel to the user process, and return it with the arg parameter. After receiving the signal, the user process parses arg to complete the timeout positioning.

[0032] Further, the content of the ioctl command protocol between the user and the driver described in the protocol definition module is: define the start timer command START_CMD (_IOW (0XEF, 0X2, unsigned long)) and the close timer command STOP_CMD (_IOW (0XEF, 0X1, unsigned long)), where 0XEF is used to specify the command type, 0X1 and 0X2 specify the command ID, and unsigned long refers to the parameter type that ioctl can carry;

[0033] Unsigned long is filled in the following format: 2 bytes of internal resource index, 1 byte of index type, 1 byte of TimerId and 1 byte of Pid, ​​where Pid is filled with the process number of the application and is sent to the correct process when the kernel driver callback is made; TimerId is filled with specific timer types according to the needs of different applications, which uniquely corresponds to a timer. Through this value, the kernel driver module corresponds to a predetermined timeout period; the internal resource index is used to mark the connection or session that started the TimerId. When the timer times out, the application can correspond to the accurate session; the index type is used to distinguish the internal resource type corresponding to the value of the resource index.

[0034] Furthermore, the protocol definition module includes:

[0035] Initialization module: used to use MKDEV to create a timer device description and register the device, initialize the operation set of the timer device, and create the timer device;

[0036] Predefined SIG_TMR signal;

[0037] Define the timer timeout processing function and set the timeout time corresponding to different timer types according to the specific application agreed rules to generate a TimerId-timeout mapping array;

[0038] Establish a driver module linked list for storing each timer request parameter;

[0039] Register the response function of the ioctl start timer command START_CMD and the close timer command STOP_CMD:

[0040] Among them, the response function logic of the start timer command START_CMD is: extract the arg parameter of the ioctl system call, read out the TimerId and obtain the timeout time of the timer according to the mapping array of TimerId-timeout time, construct the kernel timer structure struct timer_list, fill in the timeout time, timeout callback function and arg parameter according to the structure of timer_list, then call the add_timer() interface provided by the Linux kernel to start a kernel timer, and store the timer_list structure in the driver module linked list;

[0041] The response function logic of the shutdown timer command STOP_CMD is as follows: extract the arg parameter of the ioctl system call, find the timer_list structure corresponding to the arg parameter from the driver module list, call the system API del_timer() to delete the timer, and clear the corresponding information in the driver module list;

[0042] Parameter identification module: used when the application calls ioctl to the kernel driver module, the kernel driver's ioctl processing function identifies the command parameters. If a start timer command is received, the arg parameter is parsed, the TimerId is obtained and the timeout time is found. The timeout time, timeout callback function and arg parameter are filled into the timer_list structure required to start the kernel timer, and add_timer() is called to start the kernel timer and update the driver module linked list. If a stop timer command is received, the driver module linked list is searched according to the arg parameter, del_timer() is called to stop the kernel timer and delete the resources in the driver module linked list.

[0043] Timeout processing module: When the timer times out, the kernel timer module calls the timeout callback processing function and passes the arg parameter passed in when starting the timer back to the timeout callback processing function that starts the timer module. The kernel driver module obtains the Pid of the user process by parsing arg, sends a SIG_TMR signal to the process corresponding to the Pid and returns it to the user process with the arg parameter, and deletes the node that exists in the driver module linked list when the timer is started.

[0044] Furthermore, the workflow of the user state process is as follows:

[0045] Register a device file / dev / timer dedicated to the timer and obtain the file descriptor fd;

[0046] Register a function signal_handler() to handle kernel driver callback events;

[0047] Record the Pid of this process as part of the ioctl command parameters, and send the ioctl system call to the kernel driver module with different parameters.

[0048] The meanings of the above mentioned English abbreviations:

[0049] Linux: A computer operating system

[0050] ioctl: System call function for input and output device operations provided by Linux

[0051] API: Application Programming Interface

[0052] timer: timer

[0053] MKDEV: A function used in Linux systems to create device file nodes.

[0054] add_timer(): Start timer call in Linux kernel

[0055] SIGALRM: A signal provided by the Linux system, which can be registered and triggered by the alarm() / setitimer() system call

[0056] alarm(): A timer function provided by Linux that triggers a SIGALRM signal after a timeout.

[0057] Setitimer(): The timer function provided by Linux can be accurate to microseconds

[0058] SIGVTALRM: A signal provided by the Linux system, which can be registered and triggered by the setitimer() system call

[0059] SIGPROF: A signal provided by the Linux system, which can be registered and triggered by the setitimer() system call

[0060] CPU: Central Processing Unit, central processing unit

[0061] The present invention directly calls the Linux kernel timer in the kernel state by loading the kernel driver module in the application under the Linux platform, and then the application controls the kernel driver through the ioctl() system call to realize the timer start and stop operation and the transmission of timer parameters, thereby meeting the requirements of concurrent large-scale timers in the user state to start different timers in multiple connections and multiple states in the communication protocol and to be able to accurately time.

[0062] It should be understood that the contents described in the summary of the invention are not intended to limit the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] The above and other features, advantages and aspects of the embodiments of the present invention will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings.

[0064] Figure 1A flow chart of a method for implementing a large-scale accurate timer based on the Linux user mode layer according to an embodiment of the present invention is shown;

[0065] Figure 2 A block diagram of a device for implementing a large-scale accurate timer based on the Linux user mode layer according to an embodiment of the present invention is shown;

[0066] Figure 3 An implementation architecture diagram according to an embodiment of the present invention is shown;

[0067] Figure 4 A schematic diagram of the logic design of a kernel driver module according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0068] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0069] According to the implementation mode of the present invention, a method and device for realizing large-scale precise timer at the user state level based on Linux are proposed. The Linux kernel timer is directly called in the kernel state by loading the kernel driver module in the application program under the Linux platform. Then, the application program controls the kernel driver through the ioctl() system call to realize the timer start and stop operation and the timer parameter transmission. This satisfies the requirement that large-scale timers can be concurrently used in the user state to start different timers in multiple connections and multiple states in the communication protocol and to be able to accurately time.

[0070] The principle and spirit of the present invention are explained in detail below with reference to several representative embodiments of the present invention.

[0071] Figure 1 This is a flow chart of a method for implementing a large-scale accurate timer based on the user mode layer of Linux according to an embodiment of the present invention. The method includes:

[0072] S01: define the ioctl command protocol between the user and the driver. The user-mode process constructs the arg parameter with the timer parameter and the user process information through the ioctl system call and passes it to the kernel driver module.

[0073] S02: The kernel driver module identifies and processes the commands and parameters passed in by ioctl, and uses the API add_timer(struct timer_list*) provided by the Linux timer library to call the kernel timer module. The kernel driver module writes the received arg into the structure timer_list provided by the kernel timer module, and at the same time, the kernel driver module defines a timeout callback processing function and passes the function into the timer_list structure; after running the API, the kernel driver module inserts the structtimer_list* parameter information called by the API into the driver module linked list;

[0074] S03: The kernel timer module puts the timer resource started this time into the timer resource table managed by the kernel. The kernel timer module will periodically check whether there is a timer that has timed out in each clock. When it is detected that there is a timer that has timed out in the current time slot, it triggers the timeout callback processing function passed in when the add_timer() API is started, and returns the arg parameter brought in to the timeout callback processing function;

[0075] S04: The kernel driver module identifies the user process information according to the arg parameter returned by the timeout callback processing function, sends a signal from the kernel to the user process, and returns it with the arg parameter. After receiving the signal, the user process parses arg to complete the timeout positioning.

[0076] It should be noted that, although the operations of the method of the present invention are described in a specific order in the above embodiments and the accompanying drawings, this does not require or imply that the operations must be performed in the specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0077] In order to more clearly explain the above-mentioned method of implementing large-scale precise timers at the user level based on Linux, a specific embodiment is used for illustration below. However, it should be noted that this embodiment is only for better illustrating the present invention and does not constitute an improper limitation to the present invention.

[0078] The following is a specific example to further explain the method of implementing large-scale accurate timers in the user mode layer based on Linux in more detail:

[0079] A user needs to start two applications in a Linux operating system: Program A and Program B. Both applications must be able to concurrently handle connections from multiple directions. Each connection corresponds to a set of processes, and each process must have different state controls: for process A, start timer No. 1 (20 seconds) in state No. 1. If a message is received from the other party within 10 seconds, state two will be entered. If not, the connection will be disconnected. Start timer No. 2 (30 seconds) in state No. 2. If a message is received from the other party within 30 seconds, state three will be entered. If not, the connection will be disconnected. Start timer No. 3 (10s) in state No. 3. If a message is received from the other party within 10 seconds, state four will be entered. If not, the connection will be disconnected. Start timer No. 4 (60s) in state No. 4. If there is no message within 60 seconds, the connection will be disconnected. If there is message, timer No. 4 will be restarted.

[0080] Program A maintains five groups of processes, A, B, C, D, and E. Each group of processes starts timer T1, T2, T3, or T4 according to its own status. Program B also maintains five groups of processes. Each group of processes also starts timer T1, T2, T3, or T4 according to its status.

[0081] According to the method of the present invention, firstly, a kernel driver module is written and loaded in the Linux operating system to respond to ioctl commands from various application programs to the kernel.

[0082] For the five groups of processes that program A wants to concurrently start four types of timers, namely: A-A-T1, A-B-T2, A-C-T3, A-D-T4, A-E-T4. Program A calls the ioctl command to the kernel driver in batches:

[0083] ioctl(fd, START_CMD, arg), fill in the Pid of program A, related information of process A and timer number T1;

[0084] ioctl(fd, START_CMD, arg), fill in the Pid of program A, the relevant information of process B and the timer number T2;

[0085] ioctl(fd, START_CMD, arg), fill in the Pid of program A, related information of process C and timer number T3;

[0086] ioctl(fd, START_CMD, arg), fill in the Pid of program A, the relevant information of process D and timer number T4;

[0087] ioctl(fd, START_CMD, arg), fill in the Pid of program A, related information of process E and timer number T4.

[0088] Program B also needs to maintain its own resources concurrently. Assume that Program B wants to start the timers: B-A-T4, B-B-T4, B-C-T3, B-D-T2, B-E-T1. Program B calls the ioctl command to the kernel driver in batches:

[0089] ioctl(fd, START_CMD, arg), fill in the Pid of program B, related information of process A and timer number T4;

[0090] ioctl(fd, START_CMD, arg), fill in the Pid of program B, related information of process B and timer number T4;

[0091] ioctl(fd, START_CMD, arg), fill in the Pid of program B, relevant information of process C and timer number T3;

[0092] ioctl(fd, START_CMD, arg), fill in the Pid of program B, related information of process D and timer number T2

[0093] ioctl(fd, START_CMD, arg), fill in the Pid of program B, relevant information of process E and timer number T1;

[0094] After receiving the above ioctl command requests, the kernel driver module will extract the TimerId from arg for each command to find the corresponding timeout time of the timer, construct the timer_list structure together with the timeout callback function address defined by the kernel driver, call the API add_timer to notify the kernel to start the timer, and store the timer_list structure in the driver module linked list.

[0095] During the process, when process A of process Jia receives a message and needs to stop T1 and then start T2, it first calls ioctl(fd, STOP_CMD, arg). The Pid of program Jia, the information related to process A, and the timer number T1 are filled in arg. After receiving the request, the kernel driver module will parse arg, find the resource corresponding to 'Jia-A-T1' from the driver module linked list, obtain the timer_list, and then call the API del_timer to notify the kernel to stop this timer resource. Then it calls ioctl(fd, START_CMD, arg) again. The Pid of program Jia, the information related to process A, and the timer number T2 are filled in arg. After the kernel driver receives the request, it will parse arg, find the corresponding timeout of 30 seconds according to TimerId T2, construct the timer_list together with the timeout callback function address, and then call the API add_timer and store the current timer_list structure in the driver module linked list.

[0096] At a certain moment, 'Jia-C-T3' and 'Yi-A-T1' time out, and the kernel will call the timeout callback functions of the driver module twice respectively.

[0097] For 'Jia-C-T3': The timeout callback function of the kernel driver module will parse the passed-back arg parameter, obtain the Pid process number of Jia, trigger the SIG_TMR signal for process Jia, and pass back the arg parameter to process Jia. At the same time, delete the resource of this item in the driver module linked list. The signal processing function of process Jia parses arg and locates that it is the timeout of process C's T3, and then ends this process.

[0098] For 'Yi-A-T1': The timeout callback function of the kernel driver module will parse the passed-back arg parameter, obtain the Pid process number of Yi, trigger the SIG_TMR signal for process Yi, and pass back the arg parameter to process Yi. At the same time, delete the resource of this item in the driver module linked list. The signal processing function of process Yi parses arg and locates that it is the timeout of process A's T1, and then ends this process.

[0099] Based on the same inventive concept, the present invention also proposes a device for implementing a large-scale precise timer at the user space level based on Linux. The implementation of this device can refer to the implementation of the above method, and the repeated parts will not be described again. As Figure 2 shown, the device 100 includes:

[0100] Protocol definition module 101: used to define the ioctl command protocol between the user and the driver. The user space process constructs the arg parameter by passing the timer parameter and the user process information through the ioctl system call and passes it into the kernel driver module;

[0101] Command processing module 102: used for the kernel driver module to identify and process the commands and parameters passed in by ioctl, and use the API add_timer (struct timer_list*) provided by the Linux timer library to call the kernel timer module. The kernel driver module writes the received arg into the structure timer_list provided by the kernel timer module, and at the same time, the kernel driver module defines a timeout callback processing function and passes the function into the timer_list structure; after running the API, the kernel driver module inserts the struct timer_list* parameter information called by the API into the driver module linked list;

[0102] Timeout check module 103: used for the kernel timer module to put the timer resources started this time into the timer resource table managed by the kernel. The kernel timer module will periodically check whether there is a timer that has timed out in each clock. When it is checked that there is a timer that has timed out in the current time slot, it will trigger the timeout callback processing function passed in when the add_timer() API is started, and return the arg parameter brought in to the timeout callback processing function;

[0103] Timeout positioning module 104: used for the kernel driver module to identify the user process information according to the arg parameter returned by the timeout callback processing function, send a signal from the kernel to the user state process, and return it with the arg parameter. After receiving the signal, the user process parses arg to complete the timeout positioning.

[0104] Wherein, the protocol definition module 101 includes:

[0105] Initialization module 1011: used to use MKDEV to establish a timer device description and register the device, initialize the operation set of the timer device, and create the timer device;

[0106] Predefined SIG_TMR signal;

[0107] Define the timer timeout processing function and set the timeout time corresponding to different timer types according to the specific application agreed rules to generate a TimerId-timeout mapping array;

[0108] Establish a driver module linked list for storing each timer request parameter;

[0109] Register the response function of the ioctl start timer command START_CMD and the close timer command STOP_CMD:

[0110] Among them, the response function logic of the start timer command START_CMD is: extract the arg parameter of the ioctl system call, read out the TimerId and obtain the timeout time of the timer according to the mapping array of TimerId-timeout time, construct the kernel timer structure struct timer_list, fill in the timeout time, timeout callback function and arg parameter according to the structure of timer_list, then call the add_timer() interface provided by the Linux kernel to start a kernel timer, and store the timer_list structure in the driver module linked list;

[0111] The response function logic of the shutdown timer command STOP_CMD is as follows: extract the arg parameter of the ioctl system call, find the timer_list structure corresponding to the arg parameter from the driver module list, call the system API del_timer() to delete the timer, and clear the corresponding information in the driver module list;

[0112] Parameter identification module 1012: used for the kernel driver's ioctl processing function to identify the command parameters when the application calls ioctl to the kernel driver module. If a start timer command is received, the arg parameter is parsed, TimerId is obtained and the timeout time is found, and the timer_list structure required for starting the kernel timer is filled with the timeout time, timeout callback function and arg parameter, and add_timer() is called to start the kernel timer and update the driver module linked list; if a stop timer command is received, the driver module linked list is searched according to the arg parameter, del_timer() is called to stop the kernel timer, and the resources in the driver module linked list are deleted;

[0113] Timeout processing module 1013: When the timer times out, the kernel timer module calls the timeout callback processing function and returns the arg parameter passed in when starting the timer to the timeout callback processing function that starts the timer module. The kernel driver module obtains the Pid of the user process by parsing arg, sends a SIG_TMR signal to the process corresponding to the Pid and returns it to the user process with the arg parameter, and deletes the node in the driver module linked list when the timer is started.

[0114] The present invention proposes a device for realizing large-scale accurate timer at user level based on Linux. The device loads the kernel driver module through the application program under the Linux platform, directly calls the Linux kernel timer in the kernel state, and then the application program controls the kernel driver through the ioctl() system call to realize the timer start and stop operation and the timer parameter transmission. This satisfies the requirement that large-scale timers can be concurrently used in the user state to start different timers in multiple connections and multiple states in the communication protocol and can accurately time.

[0115] Although the spirit and principle of the present invention have been described with reference to several specific embodiments, it should be understood that the present invention is not limited to the disclosed specific embodiments, and the division of various aspects does not mean that the features in these aspects cannot be combined to benefit, and such division is only for the convenience of expression. The present invention is intended to cover various modifications and equivalent arrangements contained in the spirit and scope of the attached claims.

[0116] Regarding the limitation of the protection scope of the present invention, those skilled in the art should understand that, based on the technical solution of the present invention, various modifications or variations that can be made by those skilled in the art without creative work are still within the protection scope of the present invention.

Claims

1. A method for implementing a large-scale accurate timer at the user level based on Linux, characterized in that: The method includes: S01: define the ioctl command protocol between the user and the driver. The user-mode process constructs the arg parameter with the timer parameter and the user process information through the ioctl system call and passes it to the kernel driver module. S02: The kernel driver module identifies and processes the commands and parameters passed in by ioctl, and uses the API add_timer(struct timer_list*) provided by the Linux timer library to call the kernel timer module. The kernel driver module writes the received arg into the structure timer_list provided by the kernel timer module, and at the same time, the kernel driver module defines a timeout callback processing function and passes the function into the timer_list structure; after running the API, the kernel driver module inserts the struct timer_list* parameter information called by the API into the driver module linked list; S03: The kernel timer module puts the timer resource started this time into the timer resource table managed by the kernel. The kernel timer module will periodically check whether there is a timer that has timed out in each clock. When it is detected that there is a timer that has timed out in the current time slot, it triggers the timeout callback processing function passed in when the add_timer() API is started, and returns the arg parameter brought in to the timeout callback processing function; S04: The kernel driver module identifies the user process information according to the arg parameter returned by the timeout callback processing function, sends a signal from the kernel to the user process, and returns it with the arg parameter. After receiving the signal, the user process parses arg to complete the timeout positioning.

2. The method for implementing a large-scale accurate timer based on the user state layer of Linux according to claim 1, characterized in that: The content of the ioctl command protocol between the user and the driver described in S01 is: define the start timer command START_CMD (_IOW (0XEF, 0X2, unsigned long)) and the close timer command STOP_CMD (_IOW (0XEF, 0X1, unsigned long)), where 0XEF is used to specify the command type, 0X1 and 0X2 specify the command ID, and unsigned long refers to the parameter type that ioctl can carry; Unsigned long is filled in the following format: 2 bytes of internal resource index, 1 byte of index type, 1 byte of TimerId and 1 byte of Pid, ​​where Pid is filled with the process number of the application and is sent to the correct process when the kernel driver callback is made; TimerId is filled with specific timer types according to the needs of different applications, which uniquely corresponds to a timer. Through this value, the kernel driver module corresponds to a predetermined timeout period; the internal resource index is used to mark the connection or session that started the TimerId. When the timer times out, the application can correspond to the accurate session; the index type is used to distinguish the internal resource type corresponding to the value of the resource index.

3. The method for implementing a large-scale accurate timer based on the user state layer of Linux according to claim 2, characterized in that: The design logic of the kernel driver module described in S01 is: S011: Initialization work: Use MKDEV to create a timer device description and register the device, initialize the operation set of the timer device, and create the timer device; Predefined SIG_TMR signal; Define the timer timeout processing function and set the timeout time corresponding to different timer types according to the specific application agreed rules to generate a TimerId-timeout mapping array; Establish a driver module linked list for storing each timer request parameter; Register the response function of the ioctl start timer command START_CMD and the close timer command STOP_CMD: Among them, the response function logic of the start timer command START_CMD is: extract the arg parameter of the ioctl system call, read out the TimerId and obtain the timeout time of the timer according to the mapping array of TimerId-timeout time, construct the kernel timer structure struct timer_list, fill in the timeout time, timeout callback function and arg parameter according to the structure of timer_list, then call the add_timer() interface provided by the Linux kernel to start a kernel timer, and store the timer_list structure in the driver module linked list; The response function logic of the shutdown timer command STOP_CMD is as follows: extract the arg parameter of the ioctl system call, find the timer_list structure corresponding to the arg parameter from the driver module list, call the system API del_timer() to delete the timer, and clear the corresponding information in the driver module list; S012: When the application calls ioctl to the kernel driver module, the kernel driver's ioctl processing function identifies the command parameters. If a start timer command is received, the arg parameter is parsed, the TimerId is obtained and the timeout time is found. The timeout time, the timeout callback function and the arg parameter are filled into the timer_list structure required to start the kernel timer, and add_timer() is called to start the kernel timer and update the driver module linked list. If a stop timer command is received, the driver module linked list is searched according to the arg parameter, del_timer() is called to stop the kernel timer, and the resources in the driver module linked list are deleted. S013: When the timer times out, the kernel timer module calls the timeout callback processing function and passes the arg parameter passed in when starting the timer back to the timeout callback processing function that starts the timer module. The kernel driver module obtains the Pid of the user process by parsing arg, sends a SIG_TMR signal to the process corresponding to the Pid and returns it to the user process with the arg parameter, and deletes the node that exists in the driver module linked list when the timer is started.

4. The method for implementing a large-scale accurate timer based on the user mode layer of Linux according to claim 1, characterized in that: The workflow of the user state process is as follows: Register a device file / dev / timer dedicated to the timer and obtain the file descriptor fd; Register a function signal_handler() to handle kernel driver callback events; Record the Pid of this process as part of the ioctl command parameters, and send the ioctl system call to the kernel driver module with different parameters.

5. A device for implementing large-scale accurate timers at the user level based on Linux, characterized in that: The device includes: Protocol definition module: used to define the ioctl command protocol between the user and the driver. The user-mode process constructs the arg parameter of the timer parameter and the user process information and passes it to the kernel driver module through the ioctl system call. Command processing module: used by the kernel driver module to identify and process the commands and parameters passed in by ioctl, and use the API add_timer(struct timer_list*) provided by the Linuxtimer library to call the kernel timer module. The kernel driver module writes the received arg into the structure timer_list provided by the kernel timer module. At the same time, the kernel driver module defines the timeout callback processing function and passes the function into the timer_list structure. After running the API, the kernel driver module inserts the struct timer_list* parameter information called by the API into the driver module linked list; Timeout check module: used by the kernel timer module to put the timer resources started this time into the timer resource table managed by the kernel. The kernel timer module will periodically check whether there is a timeout timer in each clock. When it is detected that there is a timeout timer in the current time slot, it will trigger the timeout callback processing function passed in when starting through the add_timer() API, and return the arg parameter brought in to the timeout callback processing function; Timeout positioning module: used by the kernel driver module to identify the user process information according to the arg parameter returned by the timeout callback processing function, send a signal from the kernel to the user process, and return it with the arg parameter. After receiving the signal, the user process parses arg to complete the timeout positioning.

6. The device for implementing a large-scale accurate timer based on the user mode layer of Linux according to claim 5, characterized in that: The content of the ioctl command protocol between the user and the driver described in the protocol definition module is: define the start timer command START_CMD (_IOW (0XEF, 0X2, unsigned long)) and the close timer command STOP_CMD (_IOW (0XEF, 0X1, unsigned long)), where 0XEF is used to specify the command type, 0X1 and 0X2 specify the command ID, and unsigned long refers to the parameter type that ioctl can carry; Unsigned long is filled in the following format: 2 bytes of internal resource index, 1 byte of index type, 1 byte of TimerId and 1 byte of Pid, ​​where Pid is filled with the process number of the application and is sent to the correct process when the kernel driver callback is made; TimerId is filled with specific timer types according to the needs of different applications, which uniquely corresponds to a timer. Through this value, the kernel driver module corresponds to a predetermined timeout period; the internal resource index is used to mark the connection or session that started the TimerId. When the timer times out, the application can correspond to the accurate session; the index type is used to distinguish the internal resource type corresponding to the value of the resource index.

7. The device for implementing a large-scale accurate timer based on the user mode layer of Linux according to claim 6, characterized in that: The protocol definition module includes: Initialization module: used to use MKDEV to create a timer device description and register the device, initialize the operation set of the timer device, and create the timer device; Predefined SIG_TMR signal; Define the timer timeout processing function and set the timeout time corresponding to different timer types according to the specific application agreed rules to generate a TimerId-timeout mapping array; Establish a driver module linked list for storing each timer request parameter; Register the response function of the ioctl start timer command START_CMD and the close timer command STOP_CMD: Among them, the response function logic of the start timer command START_CMD is: extract the arg parameter of the ioctl system call, read out the TimerId and obtain the timeout time of the timer according to the mapping array of TimerId-timeout time, construct the kernel timer structure struct timer_list, fill in the timeout time, timeout callback function and arg parameter according to the structure of timer_list, then call the add_timer() interface provided by the Linux kernel to start a kernel timer, and store the timer_list structure in the driver module linked list; The response function logic of the shutdown timer command STOP_CMD is as follows: extract the arg parameter of the ioctl system call, find the timer_list structure corresponding to the arg parameter from the driver module list, call the system API del_timer() to delete the timer, and clear the corresponding information in the driver module list; Parameter identification module: used when the application calls ioctl to the kernel driver module, the kernel driver's ioctl processing function identifies the command parameters. If a start timer command is received, the arg parameter is parsed, the TimerId is obtained and the timeout time is found. The timeout time, timeout callback function and arg parameter are filled into the timer_list structure required to start the kernel timer, and add_timer() is called to start the kernel timer and update the driver module linked list. If a stop timer command is received, the driver module linked list is searched according to the arg parameter, del_timer() is called to stop the kernel timer and delete the resources in the driver module linked list. Timeout processing module: When the timer times out, the kernel timer module calls the timeout callback processing function and passes the arg parameter passed in when starting the timer back to the timeout callback processing function that starts the timer module. The kernel driver module obtains the Pid of the user process by parsing arg, sends a SIG_TMR signal to the process corresponding to the Pid and returns it to the user process with the arg parameter, and deletes the node that exists in the driver module linked list when the timer is started.

8. The device for implementing a large-scale accurate timer based on the user mode layer of Linux according to claim 5, characterized in that: The workflow of the user state process is as follows: Register a device file / dev / timer dedicated to the timer and obtain the file descriptor fd; Register a function signal_handler() to handle kernel driver callback events; Record the Pid of this process as part of the ioctl command parameters, and send the ioctl system call to the kernel driver module with different parameters.

Images