6. Writing a Comedi driver
Prev |  | Next

## 6. Writing a Comedi driver

This section explains the most important implementations aspects of the Comedi device drivers. It tries to give the interested device driver writer an overview of the different steps required to write a new device driver.

This section does not explain all implementation details of the Comedi software itself: Comedi has once and for all solved lots of boring but indispensable infrastructural things, such as: timers, management of which drivers are active, memory management for drivers and buffers, wrapping of RTOS-specific interfaces, interrupt handler management, general error handling, the `/proc` interface, etc. So, the device driver writers can concentrate on the interesting stuff: implementing their specific interface card's DAQ functionalities.

In order to make a decent Comedi device driver, you must know the answers to the following questions:

- How does the communication between user-space and kernel-space work?

- What functionality is provided by the generic kernel-space Comedi functions, and what must be provided for each specific new driver?

- How to use DMA and interrupts?

- What are the addresses and meanings of all the card's registers?

  This information is to be found in the so-called “register level manual” of the card. Without it, coding a device driver is close to hopeless. It is also something that Comedi (and hence also this handbook) cannot give any support or information for: board manufacturers all use their own design and nomenclature.

### 6.1. Communication user-space — kernel-space

In user-space, you interact with the functions implemented in the Comedilib library. Most of the device driver core of the Comedilib library is found in `lib` subdirectory.

All user-space Comedi instructions and commands are transmitted to kernel space through a traditional `ioctl` system call. (See `lib/ioctl.c` in Comedilib.) The user-space information command is encoded as a number in the `ioctl` call, and decoded in the kernel-space library. There, they are executed by their kernel-space counterparts. This is done in the `comedi_fops.c` file in the Comedi sources: the `comedi_unlocked_ioctl` function processes the results of the `ioctl` system call, interprets its contents, and then calls the corresponding kernel-space `do_…_ioctl` function(s). For example, a Comedi instruction is further processed by the `do_insn_ioctl` function. (Which, in turn, uses `parse_insn` for further detailed processing.)

The data corresponding to instructions and commands is transmitted with the `copy_from_user` function; acquisition data captured by the interface card passes the kernel/user-space boundary with the help of a `copy_to_user` function.

Prev |  | Next
5.6. Kernel drivers | Home | 6.2. Generic functionality