KR20060088929A - Apparatus and method for processing hardware interrupt in linux-based system - Google Patents

Abstract

The present invention is for hardware interrupt processing in a Linux-based system, the interrupt processing module operating in the kernel region, the process of registering a virtual device, the application program, the process of calling the first function for reading the device And setting, by the interrupt processing module, a corresponding interrupt flag bit of a virtual register existing in a user area when a hardware interrupt occurs, and returning the first function to the application program. In response to the first function returning, the application program reads a value of the virtual register to distinguish a hardware interrupt type, and wakes up a corresponding process according to the distinguished interrupt type. As described above, the present invention delivers a plurality of fast and regular interrupt signals to an application program using a single device and a device driver, and thus, hardware interrupts can be efficiently delivered to the application program.

Linux, Operating System, Interrupt, Kernel, Driver, Device

Description

Apparatus and method for processing hardware interrupt in Linux based system {APPARATUS AND METHOD FOR PROCESSING HARDWARE INTERRUPT IN LINUX-BASED SYSTEM}             

1 is a diagram illustrating an interrupt processing configuration in a system using a general operating system for an embedded system.

2 is a diagram illustrating a configuration for processing hardware interrupts in a Linux based system according to an embodiment of the present invention.

3 is a diagram showing the configuration of the VPIR 202 described in FIG.

4 is a diagram illustrating a hardware interrupt processing procedure of an application in a Linux-based system according to an embodiment of the present invention.

5 is a diagram illustrating an interrupt processing procedure of an interrupt processing module (device driver) in a Linux-based system according to an embodiment of the present invention.

6 is a diagram illustrating a mapping relationship between a system call and a device driver function in a Linux based system according to an exemplary embodiment of the present invention.

FIG. 7 illustrates read blocking of an application program in a Linux based system according to an exemplary embodiment of the present invention. FIG.

8 is a diagram illustrating a correlation between an application program and an interrupt processing module in a Linux-based system according to an embodiment of the present invention.

9 is a diagram illustrating an example of utilizing a hardware interrupt in a TDD communication system.

The present invention relates to an apparatus and method for processing hardware interrupts in a Linux based system, and more particularly, to an apparatus and method for delivering a plurality of hardware interrupts to an application program using one device driver.

Since Linux was originally developed for operating system (O / S) of servers, Kernel space and User space exist independently of each other. Therefore, an application program (application) operating in the user area cannot invade the kernel area, and can directly access hardware only in the kernel area.

Unlike Linux, operating systems that target embedded systems (pSOS, VxWorks, uClinux, etc.), as shown in Figure 1, the application interrupts the interrupt signal without intermediary interrupt register (PIR: Check the Pending Interrupt Register (not shown) to immediately execute the interrupt service routine. However, in Linux, a program running in the kernel area must register an interrupt to execute an interrupt service routine. In other words, Linux has an interrupt service routine running at the kernel level. At this time, different types of interrupt signals are separated into circuits and transferred to a kernel on a hardware chip for processing.

As such, Linux has a clear separation between user and kernel space, so if an application needs to use hardware interrupts, unlike other operating systems, it requires an intermediate medium for delivering hardware interrupts to the application. In other words, a module is needed to receive hardware interrupts from the kernel area and deliver them to higher level applications.

If an application needs to use multiple interrupt signals, registering a plurality of devices and controlling each device separately may cause cumbersome processing and inefficient operation of the application or a large amount of resources. Can be. Therefore, there is a need for a method of registering and using a plurality of hardware interrupts using fewer resources.

In addition, an application must receive and process an interrupt that is delivered at the kernel level quickly. If an interrupt that occurs at a high time interval is processed depending on the time-sharing scheduling of a general application, the application will not lose the interrupt or handle any duplicate interrupts. There is a problem. Therefore, there is a need for a method that can handle a large number of fast and continuous interrupts without loss.

 Accordingly, an object of the present invention is to provide an apparatus and method for delivering hardware interrupts to an application program via a device driver in a Linux based system.

Another object of the present invention is to provide an apparatus and method for processing hardware interrupts occurring at short time intervals in Linux-based systems with low resources without loss.

Another object of the present invention is to provide a method and method for delivering a plurality of hardware interrupts to an application program as a device driver in a Linux-based system.

According to the first aspect of the present invention for achieving the above objects, an apparatus for processing a hardware interrupt in a Linux-based system, operating in the kernel region, of the virtual register existing in the user region when a hardware interrupt occurs An interrupt processing module that sets a corresponding interrupt flag bit, returns a predetermined function to an application program unit, and distinguishes a hardware interrupt type by reading a value of the virtual register upon returning the predetermined function; And the application program unit for waking up a corresponding process according to the distinguished interrupt type.

According to a second aspect of the present invention, a hardware interrupt processing method in a Linux-based system includes a process in which an interrupt processing module operating in a kernel region registers a virtual device, and an application program reads the device. Calling the function, and the interrupt processing module sets a corresponding interrupt flag bit of a virtual register existing in the user area when a hardware interrupt occurs, and returns the first function to the application program ( returning the first function, and the application program reads the value of the virtual register to distinguish a hardware interrupt type and wakes up a corresponding process according to the distinguished interrupt type. It is characterized by.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In describing the present invention, if it is determined that the detailed description of the related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

Hereinafter, a method for processing hardware interrupts occurring at short time intervals in Linux-based systems with less resources without losing them will be described.

2 illustrates a configuration for processing hardware interrupts in a Linux-based system according to an embodiment of the present invention.

As shown, a Linux-based system is largely divided into a user space 200, a kernel area 210, and a hardware 220. According to the present invention, an interrupt processing module 211 is configured in the kernel space 210 to deliver a hardware interrupt to an application 201, and the interrupt processing is performed in the user area 200. A Virtual Pending Interrupt Register (VPIR) 202 is configured for recording interrupts delivered from module 210. In this case, the interrupt processing module 211 may be implemented using a character device driver in order to process the interrupt quickly. In this case, the characteristic device driver is a driver for supporting a characteristic device accessible as a file. On the other hand, the feature device can be represented by a stream abstraction and can be accessed by creating a file system node. Generally, device drivers exist in Linux based systems to support devices, but in the present invention, a virtual device is registered to use the device driver.

Referring to FIG. 2, an application program 201 first opens an open device call (an open system call) present in the kernel area 210 at initialization, reads the open device (lead system call), and then interrupts the application. Wait until it comes in. Subsequently, when the read function read () is returned, the application program 201 reads the value of the VPIR 202 to distinguish an interrupt type, and a corresponding thread (or process) according to the interrupt type. Wake up and perform the corresponding job.

At this time, the main process of the application 201 resets the corresponding bit of the VPIR 202 and calls the read function read () again regardless of the operation of other processes. do. In other words, the main process has a high priority so that the read function read () can be called without delay. For example, if another user tries to log in to gain shell privileges or perform file transfer using ftp (file transfer protocol), the lead system in the application 201 has a higher priority than the normal process. Problems can arise that can delay read system call timing. Therefore, the main processor is preferably set to have a higher priority than these processes. For example, the above problem does not occur when the priority of the main process (main thread) for interrupt detection is set to '30' and the priority of the general process is set to '15'.

The interrupt processing module 211 registers a virtual device of a specific device type (file type) at initialization. Subsequently, when the virtual device is opened in the application program 201, the interrupt processing module 211 prepares to receive an interrupt by releasing a mask of an interrupt signal input port and performs the corresponding interrupt. Register with the kernel (or kernel core) to use. That is, the interrupt processing module 211 registers the address of the interrupt service routine and the interrupt number to be used in the kernel. Thereafter, when the read function read () is called by the application 201, the interrupt processing module 211 waits for generation of a hardware interrupt (or execution of an interrupt service routine by calling a kernel). When the hardware interrupt occurs, the interrupt processing module 211 sets the corresponding bit of the VPIR 202 existing in the user area 200 and returns the read function to sleep. Wake up the waiting process (or thread) of the application 201.

3 illustrates the configuration of the VPIR 202 described in FIG.

As shown, the VPIR 202 according to the present invention is implemented with a virtual register of 1 byte, each bit being used as a flag indicating the type of interrupt. Here, it is assumed that the least significant bit Bit 0 is recorded with the highest priority interrupt and the most significant bit Bit 7 is recorded with the lowest priority interrupt. In this way, since the interrupt priority is determined according to the bit position of the register, when a plurality of interrupts occur simultaneously, the application program 201 may sequentially process the interrupts according to the priority. For example, assuming that two types of interrupts are used, 1 ms interrupts occurring at 1 ms intervals and 5 ms interrupts occurring at 5 ms intervals, the first bit (Bit 0) of the VPIR 202 is 1 ms. The interrupt flag bit is allocated as the interrupt flag bit, and the second bit Bit 1 is allocated as the 5ms interrupt flag bit. At this time, the reserved flag bits Bit 2 to Bit 7 may be additionally allocated whenever an interrupt to be processed is added.

As described above, the present invention is characterized by processing a plurality of interrupts using one device driver. In other words, there is also one device to be opened and read in the application program 201 and a plurality of interrupts can be handled using one device file.

4 illustrates a hardware interrupt processing procedure of an application program in a Linux based system according to an exemplary embodiment of the present invention.

Referring to FIG. 4, in operation 401, the application program 201 performs an open system call for opening a virtual characteristic device managed by the interrupt processing module 211. In this case, as shown in FIG. 6, the designated function mydevice_open of the interrupt processing module 211 is performed by the open system call.

After opening the feature device, the application 201 performs a read system call to read the feature device in step 403. In this case, as shown in FIG. 6, the designated function mydevice_read of the interrupt processing module 211 is performed by the read system call.

As such, when an application program 201 performs a system call that opens, closes, reads, or writes a device, the interrupt processing module 211 performs a system call. The specified function is executed. In other words, the device must be registered for the module of the kernel to communicate with the application. In this respect, the present invention is to register a virtual device to use a device driver (interrupt processing module).

Meanwhile, as shown in FIG. 7, the application program 201 is blocked until the corresponding function is returned after performing the read system call. When the corresponding function returns and the operation of the read function ends, the application program 201 proceeds to step 405 to read the value of the VPIR 202 to distinguish the interrupt type, and to select the thread according to the interrupt type. Wake up (or process) to perform the job.

5 illustrates an interrupt processing procedure of an interrupt processing module (device driver) in a Linux-based system according to an embodiment of the present invention.

Referring to FIG. 5, in initialization, the interrupt processing module 211 registers a virtual device in the form of a character device in step 501. In step 503, the interrupt processing module 211 determines whether the device is opened by an open system call of the application program 201. As illustrated in FIG. 6, the interrupt processing module 211 performs a function mydevice_open designated by an open system call of the application 201. By the designated function, the interrupt processing module 211 unmasks an interrupt signal input port (register) and registers the use of the interrupt in the kernel (or kernel core).

When the interrupt is ready to be received, the interrupt processing module 211 checks whether a hardware interrupt occurs in step 505. The hardware interrupt is detected in the kernel, and the kernel executes an interrupt service routine by calling an interrupt service routine in the interrupt processing module 211 when an interrupt is detected.

When the interrupt service routine is executed by the occurrence of the hardware interrupt, the interrupt processing module 211 proceeds to step 607 to check whether a read function is called by a system call of the application program 201. That is, the application program 210 checks whether it is ready to receive an interrupt.

If the read function is not called, the interrupt processing module 211 returns to step 505 to perform the following steps again. If the read function is called, the interrupt processing module 211 proceeds to step 509 and sets the corresponding interrupt flag of the VPIR 202 existing in the user area 200. In step 511, the interrupt processing module 211 returns the read function to the application program 201 to wake up the thread (or process), and then returns to step 505.

8 is a diagram illustrating a correlation between an application program and an interrupt processing module in a Linux-based system according to an embodiment of the present invention.

Referring to FIG. 8, first, the interrupt processing module 211 registers a virtual device in the form of a characteristic device upon initialization. Generally, device drivers in Linux-based systems manage devices, but in the present invention, a virtual device is registered in order to use a device driver (interrupt processing module). After registering the virtual device, the interrupt processing module 211 waits until an application program 201 makes an open system call. That is, the interrupt processing module 211 operates in an event driven manner.

In operation 803, the application program 201 performs an open system call to open the virtual device. In response to the open system call, the interrupt processing module 211 performs the function mydevice_open specified in step 805. By the designated function, the interrupt processing module 211 unmasks an interrupt signal input port and requests an interrupt from the kernel to use the interrupt.

After issuing the open system call, the application program 201 prepares to receive a hardware interrupt by performing a read system call in step 807. Here, after the application program 201 performs the read system call, the application program 201 is blocked until the corresponding function is returned.

In response to the read system call, the interrupt processing module 211 performs the function mydevice_read specified in step 809. After performing the designated function, the interrupt processing module 211 waits for generation of a hardware interrupt in step 811. The hardware interrupt is detected in a kernel, and when the interrupt is detected, the kernel calls an interrupt service routine in the interrupt processing module 211 to execute an interrupt service routine.

When the interrupt service routine is performed by the hardware interrupt, the interrupt processing module 211 proceeds to step 813 to set the corresponding interrupt flag of the VPIR 202 existing in the user area 200. In step 815, the interrupt processing module 211 returns the read function to the application program 201 and returns to step 811.

On the other hand, when the read function is returned, the application program 201 reads the value of the VPIR 202 to identify the type of interrupt in step 817. In operation 819, the application program 201 wakes up the thread (or process) according to the interrupt type to perform a corresponding job. At the same time, the application program 201 returns to step 809 by the main process waiting for an interrupt, and performs the following steps again. That is, the main process of the application 201 checks only the information of the VPIR 202 regardless of the operation of other processes, and immediately executes a read system call again to wait for the next interrupt. In this way, the main process (thread) waiting for an interrupt in an application program is set to have a high priority so as not to miss the timing of calling a read function by being pushed to another process.

Hereinafter, a communication system operating in a time division duplex (TDD) scheme will be described as an example for better understanding of the present invention.

The TDD scheme distinguishes an uplink and a downlink between a terminal and a base station by time. In a communication system using the TDD scheme, for example, an application operates according to a 5 ms clock that determines a frame reference point and a 1 ms clock that determines a start time of a task. Therefore, in order for an application to function properly, clocks (or timer interrupts) generated by hardware must be delivered to the application program correctly without being lost. To this end, the present invention implements an interrupt processing module in the form of a specific device driver in the kernel region, receives a hardware interrupt from the interrupt processing module, and delivers it to an application program. Next, an example of using hardware interrupts in the application program will be described in detail.

9 is a diagram illustrating an example of using a hardware interrupt in a TDD communication system.

As shown in the figure, the hardware generates 5 ms interrupts (or ticks) at 5 ms intervals and 1 ms interrupts at 1 ms intervals in synchronization with the GPS (Global Positioning System) clock. The interrupts generated as described above are transmitted to the application program 201 by the interrupt processing module 211 according to the present invention.

Reference numeral 901 denotes a 5 ms interrupt, and reference numerals 903 to 911 denote a 1 ms interrupt. Five 1ms thread control ticks occur during a 5ms interval based on a 5ms frame tick. That is, a frame starts every 5ms, and counts up 1ms ticks to perform a corresponding job. It wakes up the thread every 1ms to perform its task, and it can recognize other interrupts and start other tasks while other threads (or processes) are running.

If a 5ms interrupt 901 is detected by reading the VPIR 202, the application 201 recognizes the start of the frame and waits for the next 1ms interrupt. After the first 1 ms interrupt 903 is detected, the application 201 wakes up Thread 2 and writes a downlink control message in memory to perform downlink communication. . Here, the first 1ms interrupt is generated when a predetermined time (??) has elapsed from the time when the 5ms interrupt 901 occurs according to a predetermined standard as shown.

Then, when the second 1ms interrupt is detected, the application program 201 wakes up Thread3 and reads data from memory. Thereafter, when the third 1ms interrupt is detected, the application program 201 wakes up Thread1 and performs a corresponding task (Read uplink). At this time, the thread 3 performs a write operation by the third 1ms interrupt.

Then, when the fourth 1ms interrupt is detected, the application program 201 performs uplink communication by waking up the thread 3 and performing a write operation. Then, when the 5ms interrupt is detected again, the application program 201 proceeds to work on the next frame.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined not only by the scope of the following claims, but also by those equivalent to the scope of the claims.

As described above, the present invention can efficiently deliver hardware interrupts to an application program in a Linux system. In particular, since it transmits a number of fast and regular interrupt signals to an application program using one device and a device driver, hardware interrupts can be processed with less resources. In addition, by giving a high priority to a thread waiting for an interrupt, there is an advantage that can be handled without losing hardware interrupts.

Claims (19)

Apparatus for handling hardware interrupts in Linux based systems, An interrupt processing module that operates in the kernel area, sets a corresponding interrupt flag bit of a virtual register existing in the user area when a hardware interrupt occurs, and returns a predetermined function to the application program unit; , And an application program unit configured to read a value of the virtual register to distinguish a hardware interrupt type when the predetermined function returns, and to wake up a corresponding process according to the distinguished interrupt type. The method of claim 1, And said interrupt processing module is a characteristic device driver. The method of claim 1, And the interrupt processing module registers a character device to transfer information to the application program unit upon initialization. The method of claim 3, The predetermined function is a read function for reading the characteristic device. The method of claim 1, And the application program unit issues a system call to call the predetermined function and is blocked until the predetermined function is returned. The method of claim 1, And said interrupt processing module operates in an event driven manner. The method of claim 1, The application program unit, after distinguishing the interrupt type, characterized in that for resetting the virtual register (Reset), and issuing a system call to call the predetermined function again. The method of claim 7, wherein Wherein the process of issuing a system call to call the predetermined function has a higher priority than normal processes. The method of claim 1, And upon issuing an open function system call in the application program unit, the interrupt processing module releases a mask of an interrupt signal input port and registers the use of the corresponding interrupt in the kernel. The method of claim 1, The virtual register is declared in the form of a variable of 1 byte, each bit is used as a flag indicating the type of interrupt. In the hardware interrupt handling method in Linux based system, An interrupt processing module operating in the kernel region registers a virtual device, An application program, calling a first function for reading the device; Setting, by the interrupt processing module, a corresponding interrupt flag bit of a virtual register existing in a user area when a hardware interrupt occurs, and returning the first function to the application program; And upon the return of the first function, the application program to read a value of the virtual register to distinguish a hardware interrupt type, and to wake up the process according to the distinguished interrupt type. The method of claim 11, And said interrupt processing module is a character device driver. The method of claim 1, And said virtual device is a character device. The method of claim 11, And the application program is blocked until the first function is called and the first function is returned. The method of claim 11, And wherein said interrupt handling module operates in an event driven manner. The method of claim 11, After distinguishing the hardware interrupt, the application program further comprising: resetting the virtual register and calling the first function again. The method of claim 16, The process calling the first function has a higher priority than normal processes. The method of claim 11, Calling, by the application program, a second function for opening the device; And removing, by the interrupt processing module, the mask of the interrupt signal input port by the second function call and registering the use of the corresponding interrupt in the kernel. The method of claim 11, The virtual register is declared in the form of a variable of 1 byte, wherein each bit is used as a flag indicating the type of interrupt.

Images