6.5. Device driver caveats
Prev | 6. Writing a Comedi driver | Next

### 6.5. Device driver caveats

A few things to strive for when writing a new driver:

- Some DAQ cards consist of different “layers” of hardware, which can each be given their own device driver. Examples are: some of the National Instruments cards, that all share the same Mite PCI driver chip; the ubiquitous parallel port, that can be used for simple digital IO acquisitions. If your new card has such a multi-layer design too, please take the effort to provide drivers for each layer separately.

- Your hardware driver should be functional appropriate to the resources allocated. I.e., if the driver is fully functional when configured with an IRQ and DMA, it should still function moderately well with just an IRQ, or still do minor tasks without IRQ or DMA. Does your driver really require an IRQ to do digital I/O? Maybe someone will want to use your driver just to do digital I/O and has no interrupts available.

- Drivers are to have absolutely no global variables (apart from read-only, constant data, or data structures shared by all devices), mainly because the existence of global variables immediately negates any possibility of using the driver for two devices. The pointer `dev->private` should be used to point to a structure containing any additional variables needed by a driver/device combination.

- Drivers should report errors and warnings via the `comedi_error` function. (This is not the same function as the user-space `comedi_perror` function.)

Prev | Up | Next
6.4. Callbacks, events and interrupts | Home | 6.6. Integrating the driver in the Comedi library