
Comedi
141 / 148
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.
6.2 Generic functionality
The major include files of the kernel-space part of Comedi are:
• include/linux/comedidev.h: the header file for kernel-only structures (device, subdevice, async (i.e., buffer/event/in-
terrupt/callback functionality for asynchronous DAQ in a Comedi command), driver, lrange), variables, inline functions and
constants.
• include/linux/comedi_rt.h: all the real-time stuff, such as management of ISR in RTAI and RTLinux/Free, and
spinlocks for atomic sections.
• include/linux/comedilib.h: the header file for the kernel library of Comedi (kcomedilib module).
From all the relevant Comedi device driver code that is found in the comedi kernel module source directory, the generic
functionality is contained in two parts:
• A couple of C files contain the infrastructural support. From these C files, it’s especially the comedi_fops.c file that
implements what makes Comedi into what people want to use it for: a library that has solved 90% of the DAQ device driver
efforts, once and for all.
• For real-time applications, the subdirectory kcomedilib implements an interface in the kernel that is similar to the Comedi
interface accessible through the user-space Comedi library.
There are some differences in what is possible and/or needed in kernel-space and in user-space, so the functionalities offered in
kcomedilib are not an exact copy of the user-space library. For example, locking, interrupt handling, real-time execution,
callback handling, etc., are only available in kernel-space.
Most drivers don’t make use (yet) of these real-time functionalities.
6.2.1 Data structures
This Section explains the generic data structures that a device driver interacts with:
typedef struct comedi_lrange_struct comedi_lrange;
typedef struct comedi_subdevice_struct comedi_subdevice;
typedef struct comedi_device_struct comedi_device:
typedef struct comedi_async_struct comedi_async
typedef struct comedi_driver_struct comedi_driver;
They can be found in include/linux/comedidev.h. Most of the fields are filled in by the Comedi infrastructure, but
there are still quite a handful that your driver must provide or use. As for the user-level Comedi, each of the hierarchical layers
has its own data structures: range (comedi_lrange), subdevice, and device.
Note that these kernel-space data structures have similar names as their user-space equivalents, but they have a different (kernel-
side) view on the DAQ problem and a different meaning: they encode the interaction with the hardware, not with the user.
However, the comedi_insn and comedi_cmd data structures are shared between user-space and kernel-space: this should come
as no surprise, since these data structures contain all information that the user-space program must transfer to the kernel-space
driver for each acquisition.
Komentáře k této Příručce