Additional Information: Managing Interrupts and Concurrency

Recalling what we did in Chapter 3, Working with Char Drivers, when we talked about the read() system call and how we can implement it for our char driver (see chapter_4/chrdev/chrdev.c file on GitHub), we noticed that our implementation was tricky because data was always available:

static ssize_t chrdev_read(struct file *filp,
               char __user *buf, size_t count, loff_t *ppos)
{
    struct chrdev_device *chrdev = filp->private_data;
    int ret;

    dev_info(chrdev->dev, "should read %ld bytes (*ppos=%lld)\n",
                count, *ppos);

    /* Check for end-of-buffer */
    if (*ppos + count >= BUF_LEN)
        count = BUF_LEN - *ppos;

    /* Return data to the user space */
    ret = copy_to_user(buf, chrdev->buf + *ppos, count);
    if (ret < 0)
        return ret;

    *ppos += count;
    dev_info...

Deferring work

A long time ago, there were the bottom halves, that is, a hardware event was split into two halves: the top half (the hardware interrupt handler) and the bottom half (the software interrupt handler). This is because an interrupt handler must execute as quickly as possible to be ready to serve the next incoming interrupts, so, for instance, the CPU cannot stay for a long time in the interrupt handler's body waiting for the slow peripheral sending or receiving of its data. That's why we used bottom halves; interrupts were split into two parts: the top one, the real hardware interrupt handler, which executes quickly and with disabled interrupts that simply acknowledges the peripheral and then starts a bottom half, executed with enabled interrupts, which can safely complete the sending/receiving job by taking its time.

However, bottom halves were very limiting...

Kernel timers

A kernel timer is an easy way to ask the kernel to execute a specific function after a well-defined amount of time. Linux implements two different types of kernel timers: old but still valid kernel timers defined in the linux/include/linux/timer.h header file and new high-resolution kernel timers defined in the linux/include/linux/hrtimer.h header file. Even if they are implemented differently, both mechanisms work in a very similar manner: we have to declare a structure holding timer's data, which can be initialized by proper functions, and then the timer can be started using the proper function. Once expired, the timer calls a handler to execute the desired actions and, eventually, we have the possibility of stopping or restarting the timer.

Legacy kernel timers are only supported at a resolution of 1 jiffy. The length of a jiffy is dependent on the value...