Linux Kernel & Device Driver Programming

Event-Driven Programming

This file uses the W3C HTML Slidy format. The "a" key toggles between one-slide-at-a-time and single-page mode, and the "c" key toggles on and off the table of contents. The ← and → keys can be used to page forward and backward. For more help on controls see the "help?" link at the bottom.

Event-Driven Programming

Device drivers differ from most conventional programs, but are similar to applications driven by graphical user interfaces, in that they are event driven.

They execute actions in response to external events, via handlers
They not have a thread of control that can suspend to wait for an event, and then resume
Instead, handlers execute to completion and rely a future event to trigger them to execute again
The logic needs to be designed in terms of a state machine, that can "remember" what needs to be done the next time the handler executes

Examples

The following two examples demonstrate the difference between a conventional sequential programming style, and an event-driven style.

These are both written user-level C programs, not as kernel modules.

Please keep in mind that event-driven programming in the OS kernel uses different primitives.

For example, instead of installing a signal handler for SIGALRM and using alarm() to generate the next signal, one would use a kernel timer to achieve a similar effect.

Using a conventional sequential thread

  int i = 1;
  for (;;i++) {
    fprintf (stderr, "%d\n", i);
    sleep (1);
  }

Using an event handler

A state variable
```
volatile int k = 1;
```

An event handler

void handler () {
  fprintf (stderr, "%d\n", k++);
  alarm (1);  /* schedule next event */
}

Initialization

sigaction (SIGALRM, NULL, &act);
act.sa_handler = handler;
sigaction (SIGALRM, &act, NULL);
alarm (1); /* trigger the first event */