1 <?xml version="1.0" encoding="utf-8"?>
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3 "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
4 <!ENTITY % comedilib_entities SYSTEM "comedilib.ent">
8 <section id="driverwriting">
10 Writing a &comedi; driver
14 This Section explains the most important implementations aspects of
15 the &comedi; device drivers. It tries to give the interested device
16 driver writer an overview of the different steps required to write a
20 This Section does <emphasis>not</emphasis> explain all implementation
21 details of the &comedi; software itself: &comedi; has once and for
22 all solved lots of boring but indispensable infrastructural things,
23 such as: timers, management of which drivers
24 are active, memory management for drivers and buffers, wrapping
25 of RTOS-specific interfaces, interrupt handler management, general
26 error handling, the <filename role="directory">/proc</filename>
28 the device driver writers can concentrate on the interesting stuff:
29 implementing their specific interface card's DAQ functionalities.
32 In order to make a decent &comedi; device driver, you must
33 know the answers to the following questions:
39 <link linkend="userkernelhow">communication</link> between user space
40 and kernel space work?
46 What functionality is provided by the
47 <link linkend="comedikernelgeneric">generic</link> kernel-space
48 &comedi; functions, and what must be provided for each
49 <link linkend="boardspecific">specific new driver</link>?
55 How to use <link linkend="drivercallbacks">DMA and interrupts</link>?
61 What are the addresses and meanings of all the card's registers?
64 This information is to be found in the so-called <quote>register level
65 manual</quote> of the card. Without it, coding a device driver is close
66 to hopeless. It is also something that &comedi; (and hence also this
67 handbook) cannot give any support or information for: board
68 manufacturers all use their own design and nomenclature.
75 <section id="userkernelhow">
77 Communication user space-kernel space
81 In user space, you interact with the functions implemented in the
82 <filename role="directory">/usr/src/comedilib</filename> directory. Most
83 of the device driver core of the Comedilib library is found in
84 <filename role="directory">lib</filename> subdirectory.
87 All user-space &comedi;
88 <link linkend="instructions">instructions</link> and
89 <link linkend="commandsstreaming">commands</link>
90 are transmitted to kernel space through a traditional
91 <function>ioctl</function> system call.
92 (See <filename>/usr/src/comedilib/lib/ioctl.c</filename>.)
93 The user space information command is <emphasis>encoded</emphasis> as
94 a number in the <function>ioctl</function> call, and decoded in the
95 kernel space library. There, they are executed by their kernel-space
96 counterparts. This is done in the
97 <filename>/usr/src/comedi/comedi/comedi_fops.c</filename> file: the
98 <function>comedi_ioctl()</function> function processes the results of
99 the <function>ioctl</function> system call, interprets its contents,
100 and then calls the corresponding kernel space
101 <function>do_…_ioctl</function> function(s).
102 For example, a &comedi;
103 <link linkend="instructions">instruction</link> is further processed
104 by the <function>do_insn_ioctl()</function>function. (Which, in turn,
105 uses <function>parse_insn()</function> for further detailed processing.)
108 The data corresponding to instructions and commands is transmitted
109 with the <function>copy_from_user()</function> system call;
110 acquisition data captured by the interface card passes the kernel-user
111 space boundary with the help of a <function>copy_to_user()</function>
117 <section id="comedikernelgeneric">
119 Generic functionality
123 The major include files of the kernel-space part of &comedi; are:
128 <filename>include/linux/comedidev.h</filename>: the
129 header file for kernel-only structures (device, subdevice, async
130 (i.e., buffer/event/interrupt/callback functionality for asynchronous
131 DAQ in a &comedi; command), driver, lrange), variables, inline functions
138 <filename>include/linux/comedi_rt.h</filename>:
139 all the real-time stuff, such as management of ISR in RTAI and
140 RTLinux/Free, and spinlocks for atomic sections.
146 <filename>include/linux/comedilib.h</filename>: the header file for
147 the kernel library of &comedi;.
154 From all the relevant &comedi; device driver code that is found in the
155 <filename role="directory">/usr/src/comedi/comedi</filename> directory
156 (<emphasis>if</emphasis> the &comedi; source has been installed in its
157 normal <filename role="directory">/usr/src/comedi</filename> location),
158 the <emphasis role="strong">generic</emphasis> functionality is
159 contained in two parts:
164 A couple of <filename>C</filename> files contain the <emphasis
165 role="strong">infrastructural support</emphasis>.
166 From these <filename>C</filename> files, it's especially the
167 <filename>comedi_fops.c</filename> file that implements what makes
168 &comedi; into what people want to use it for: a library that has
169 solved 90% of the DAQ device driver efforts, once and for all.
175 For <emphasis role="strong">real-time</emphasis> applications,
176 the subdirectory <filename role="directory">kcomedilib</filename>
177 implements an interface in the kernel that is similar to the &comedi;
178 interface accessible through the
179 <link linkend="functionreference">user-space Comedi library</link>.
182 There are some differences in what is possible and/or needed
183 in kernel space and in user space, so the functionalities offered in
184 <filename role="directory">kcomedilib</filename> are not an exact copy
185 of the user-space library. For example, locking, interrupt handling,
186 real-time execution, callback handling, etc., are only available in
190 Most drivers don't make use (yet) of these real-time functionalities.
198 <section id="driverdatastructures">
204 This Section explains the generic data structures that a device driver
207 typedef struct comedi_lrange_struct <link linkend="comedilrange">comedi_lrange</link>;
208 typedef struct comedi_subdevice_struct <link linkend="comedisubdevice">comedi_subdevice</link>;
209 typedef struct comedi_device_struct <link linkend="comedidevice">comedi_device</link>:
210 typedef struct comedi_async_struct <link linkend="comediasync">comedi_async</link>
211 typedef struct comedi_driver_struct <link linkend="comedidriver">comedi_driver</link>;
214 <filename>/usr/src/comedi/include/linux/comedidev.h</filename>.
215 Most of the fields are filled in by the &comedi; infrastructure, but
216 there are still quite a handful that your driver must provide or use.
217 As for the user-level &comedi;, each of the hierarchical layers has
218 its own data structures: channel (<function>comedi_lrange</function>),
219 subdevice, and device.
222 Note that these kernel-space data structures have similar names as
224 <link linkend="datatypesstructures">user-space equivalents</link>, but
225 they have a different (kernel-side) view on the DAQ problem and a
226 different meaning: they encode the interaction with the
227 <emphasis>hardware</emphasis>, not with the <emphasis>user</emphasis>.
230 However, the <link linkend="ref-type-comedi-insn">comedi_insn</link>
231 and <link linkend="ref-type-comedi-cmd">comedi_cmd</link>
232 data structures are shared between user space and kernel space: this
233 should come as no surprise, since these data structures contain all
234 information that the user-space program must transfer to the
235 kernel-space driver for each acquisition.
238 In addition to these data entities that are also known at the user
239 level (device, sub-device, channel), the device driver level provides
240 two more data structures which the application programmer doesn't get
241 in touch with: the data structure
242 <link linkend="comedidriver">comedi_driver</link>
243 that stores the device driver information that is relevant at the
244 operating system level, and the data structure
245 <link linkend="comediasync">comedi_async</link> that stores the
246 information about all <emphasis>asynchronous</emphasis> activities
247 (interrupts, callbacks and events).
250 <section id="comedilrange">
252 <function>comedi_lrange</function>
255 The channel information is simple, since it contains only the signal
258 struct comedi_lrange_struct{
260 <link linkend="ref-type-comedi-krange">comedi_krange</link> range[GCC_ZERO_LENGTH_ARRAY];
268 <section id="comedisubdevice">
270 <function>comedi_subdevice</function>
273 The subdevice is the smallest &comedi; entity that can be used for
274 <quote>stand-alone</quote> DAQ, so it is no surprise that it is
277 struct comedi_subdevice_struct{
281 int len_chanlist; /* maximum length of channel/gain list */
285 <link linkend="comediasync">comedi_async</link> *async;
289 unsigned int runflags;
293 <link linkend="ref-type-lsampl-t">lsampl_t</link> maxdata; /* if maxdata==0, use list */
294 <link linkend="ref-type-lsampl-t">lsampl_t</link> *maxdata_list; /* list is channel specific */
297 unsigned int *flaglist;
299 <link linkend="comedilrange">comedi_lrange</link> *range_table;
300 <link linkend="comedilrange">comedi_lrange</link> **range_table_list;
302 unsigned int *chanlist; /* driver-owned chanlist (not used) */
304 int (*insn_read)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *,<link linkend="ref-type-comedi-insn">comedi_insn</link> *,<link linkend="ref-type-lsampl-t">lsampl_t</link> *);
305 int (*insn_write)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *,<link linkend="ref-type-comedi-insn">comedi_insn</link> *,<link linkend="ref-type-lsampl-t">lsampl_t</link> *);
306 int (*insn_bits)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *,<link linkend="ref-type-comedi-insn">comedi_insn</link> *,<link linkend="ref-type-lsampl-t">lsampl_t</link> *);
307 int (*insn_config)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *,<link linkend="ref-type-comedi-insn">comedi_insn</link> *,<link linkend="ref-type-lsampl-t">lsampl_t</link> *);
309 int (*do_cmd)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *);
310 int (*do_cmdtest)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *,<link linkend="ref-type-comedi-cmd">comedi_cmd</link> *);
311 int (*poll)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *);
312 int (*cancel)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *);
314 int (*buf_change)(<link linkend="comedidevice">comedi_device</link> *,<link linkend="comedisubdevice">comedi_subdevice</link> *s,unsigned long new_size);
315 void (*munge)(<link linkend="comedidevice">comedi_device</link> *, <link linkend="comedisubdevice">comedi_subdevice</link> *s, void *data, unsigned int num_bytes, unsigned int start_chan_index );
320 The function pointers <function>(*insn_read)</function> …
321 <function>(*cancel)</function> .
322 offer (pointers to) the standardized
323 <link linkend="functionreference">user-visible API</link>
324 that every subdevice should offer; every device driver has to fill
325 in these functions with their board-specific implementations.
326 (Functionality for which &comedi; provides generic functions will, by
327 definition, not show up in the device driver data structures.)
330 The <function>buf_change()</function> and <function>munge()</function>
331 functions offer functionality that is not visible to the user and for
332 which the device driver writer must provide a board-specific
334 <function>buf_change()</function> is called when a change in the
335 data buffer requires handling; <function>munge()</function> transforms
336 different bit-representations of DAQ values, for example from
337 <emphasis>unsigned</emphasis> to <emphasis>2's complement</emphasis>.
342 <section id="comedidevice">
344 <function>comedi_device</function>
348 The last data structure stores the information at the
349 <emphasis>device</emphasis> level:
351 struct comedi_device_struct{
353 <link linkend="comedidriver">comedi_driver</link> *driver;
357 const void *board_ptr;
361 int in_request_module;
364 <link linkend="comedisubdevice">comedi_subdevice</link> *subdevices;
365 int options[COMEDI_NDEVCONFOPTS];
371 <link linkend="comedisubdevice">comedi_subdevice</link> *read_subdev;
372 wait_queue_head_t read_wait;
374 <link linkend="comedisubdevice">comedi_subdevice</link> *write_subdev;
375 wait_queue_head_t write_wait;
377 struct fasync_struct *async_queue;
379 void (*open)(<link linkend="comedidevice">comedi_device</link> *dev);
380 void (*close)(<link linkend="comedidevice">comedi_device</link> *dev);
387 <section id="comediasync">
389 <function>comedi_async</function>
393 The following data structure contains all relevant information:
394 addresses and sizes of buffers, pointers to the actual data, and the
395 information needed for
396 <link linkend="drivercallbacks">event handling</link>:
398 struct comedi_async_struct{
399 void *prealloc_buf; /* pre-allocated buffer */
400 unsigned int prealloc_bufsz; /* buffer size, in bytes */
401 unsigned long *buf_page_list; /* physical address of each page */
402 unsigned int max_bufsize; /* maximum buffer size, bytes */
403 unsigned int mmap_count; /* current number of mmaps of prealloc_buf */
405 volatile unsigned int buf_write_count; /* byte count for writer (write completed) */
406 volatile unsigned int buf_write_alloc_count; /* byte count for writer (allocated for writing) */
407 volatile unsigned int buf_read_count; /* byte count for reader (read completed)*/
409 unsigned int buf_write_ptr; /* buffer marker for writer */
410 unsigned int buf_read_ptr; /* buffer marker for reader */
412 unsigned int cur_chan; /* useless channel marker for interrupt */
413 /* number of bytes that have been received for current scan */
414 unsigned int scan_progress;
415 /* keeps track of where we are in chanlist as for munging */
416 unsigned int munge_chan;
418 unsigned int events; /* events that have occurred */
420 <link linkend="ref-type-comedi-cmd">comedi_cmd</link> cmd;
423 unsigned int cb_mask;
424 int (*cb_func)(unsigned int flags,void *);
427 int (*inttrig)(<link linkend="comedidevice">comedi_device</link> *dev,<link linkend="comedisubdevice">comedi_subdevice</link> *s,unsigned int x);
434 <section id="comedidriver">
436 <function>comedi_driver</function>
441 struct comedi_driver_struct{
442 struct comedi_driver_struct *next;
445 struct module *module;
446 int (*attach)(<link linkend="comedidevice">comedi_device</link> *,comedi_devconfig *);
447 int (*detach)(<link linkend="comedidevice">comedi_device</link> *);
449 /* number of elements in board_name and board_id arrays */
450 unsigned int num_names;
452 /* offset in bytes from one board name pointer to the next */
463 <section id="driversupportfunctions">
465 Generic driver support functions
470 <filename role="directory">comedi</filename> contains a large set of
471 support functions. Some of the most important ones are given below.
474 From <filename>comedi/comedi_fops.c</filename>, functions to handle the
475 hardware events (which also runs the registered callback function), to
476 get data in and out of the software data buffer, and to parse the
477 incoming functional requests:
479 void comedi_event(<link linkend="comedidevice">comedi_device</link> *dev,<link linkend="comedisubdevice">comedi_subdevice</link> *s,unsigned int mask);
481 int comedi_buf_put(<link linkend="comediasync">comedi_async</link> *async, <link linkend="ref-type-sampl-t">sampl_t</link> x);
482 int comedi_buf_get(<link linkend="comediasync">comedi_async</link> *async, <link linkend="ref-type-sampl-t">sampl_t</link> *x);
484 static int parse_insn(<link linkend="comedidevice">comedi_device</link> *dev,<link linkend="ref-type-comedi-insn">comedi_insn</link> *insn,<link linkend="ref-type-lsampl-t">lsampl_t</link> *data,void *file);
486 The file <filename>comedi/kcomedilib/kcomedilib_main.c</filename> provides
487 functions to register a callback, to poll an ongoing data acquisition,
488 and to print an error message:
490 int comedi_register_callback(<link linkend="ref-type-comedi-t">comedi_t</link> *d,unsigned int subdevice, unsigned int mask,int (*cb)(unsigned int,void *),void *arg);
492 int comedi_poll(<link linkend="ref-type-comedi-t">comedi_t</link> *d, unsigned int subdevice);
494 void comedi_perror(const char *message);
496 The file <filename>comedi/rt.c</filename> provides interrupt handling
497 for real-time tasks (one interrupt per <emphasis>device</emphasis>!):
499 int comedi_request_irq(unsigned irq,void (*handler)(int, void *,struct pt_regs *), unsigned long flags,const char *device,<link linkend="comedidevice">comedi_device</link> *dev_id);
500 void comedi_free_irq(unsigned int irq,<link linkend="comedidevice">comedi_device</link> *dev_id)
509 <section id="boardspecific">
511 Board-specific functionality
515 The <filename role="directory">/usr/src/comedi/comedi/drivers</filename>
516 subdirectory contains
517 the <emphasis role="strong">board-specific</emphasis> device driver
518 code. Each new card must get an entry in this directory.
519 <emphasis role="strong">Or</emphasis>
520 extend the functionality of an already existing driver file if the new
521 card is quite similar to that implemented in an already existing
522 driver. For example, many of the National Instruments DAQ cards use
523 the same driver files.
526 To help device driver writers,
527 &comedi; provides the <quote>skeleton</quote> of a new device driver,
528 in the <filename>comedi/drivers/skel.c</filename> file. Before
529 starting to write a new driver, make sure you understand this file,
530 and compare it to what you find in the other already available
531 board-specific files in the same directory.
534 The first thing you notice in <filename>skel.c</filename> is the
535 documentation section: the &comedi; documentation is partially
536 generated automatically, from the information that is given in this
537 section. So, please comply with the structure and the keywords
538 provided as &comedi; standards.
541 The second part of the device driver contains board-specific static
542 data structure and defines: addresses of hardware registers; defines and
543 function prototypes for functionality that is only used inside of the
544 device driver for this board; the encoding of the types and number of
545 available channels; PCI information; etc.
548 Each driver has to register two functions which are called when you
549 load and unload your board's device driver (typically via a kernel
555 In the <quote>attach</quote> function, memory is allocated for the
556 necessary <link linkend="driverdatastructures">data structures</link>,
557 all properties of a device and its subdevices are defined, and filled
558 in in the generic &comedi; data structures. As part of this, pointers
559 to the low level instructions being supported by the subdevice have to
560 be set, which define the basic functionality. In somewhat more detail,
561 the <function>mydriver_attach()</function> function must:
566 check and request the I/O port region, IRQ, DMA, and other hardware
567 resources. It is convenient here if you verify the existence of the
568 hardware and the correctness of the other information given.
569 Sometimes, unfortunately, this cannot be done.
575 allocate memory for the private data structures.
581 initialize the board registers and possible subdevices (timer, DMA, PCI,
582 hardware FIFO, etc.).
588 return 1, indicating success. If there were any errors along the way,
589 you should return the appropriate error number. If an error is
590 returned, the <function>mydriver_detach()</function> function is
591 called. The <function>mydriver_detach()</function> function should
592 check any resources that may have been allocated and release them as
593 necessary. The &comedi; core frees
594 <function>dev->subdevices</function> and
595 <function>dev->private</function>, so this does not need to be done in
596 <function>detach</function>.
602 If the driver has the possibility to offer asynchronous data
603 acquisition, you have to code an interrupt service routine, event
604 handling routines, and/or callback routines.
609 Typically, you will be able to implement most of
610 the above-mentioned functionality by
611 <emphasis>cut-and-paste</emphasis> from already existing drivers. The
612 <function>mydriver_attach()</function> function needs most of your
613 attention, because it must correctly define and allocate the (private
614 and generic) data structures that are needed for this device. That is,
615 each sub-device and each channel must get appropriate data fields, and
616 an appropriate initialization. The good news, of course, is that
617 &comedi; provides the data structures and the defines that fit very
618 well with almost all DAQ functionalities found on interface cards.
619 These can be found in the
620 <link linkend="comedikernelgeneric">header files</link> of the
621 <filename role="directory">/usr/src/comedi/include/linux/</filename>
625 Drivers for digital IOs should implement the following functions:
630 <function>insn_bits()</function>: drivers set this if they have a
631 function that supports reading and writing multiple bits in a digital
632 I/O subdevice at the same time. Most (if not all) of the drivers use
633 this interface instead of insn_read and insn_write for DIO subdevices.
639 <function>insn_config()</function>: implements INSN_CONFIG
640 instructions. Currently used for configuring the direction of digital
641 I/O lines, although will eventually be used for generic configuration
642 of drivers that is outside the scope of the currently defined &comedi;
648 Finally, the device driver writer must implement the
649 <function>read</function> and <function>write</function> functions for
650 the analog channels on the card:
655 <function>insn_read()</function>: acquire the inputs on the board and
656 transfer them to the software buffer of the driver.
662 <function>insn_write()</function>: transfer data from the software
663 buffer to the card, and execute the appropriate output conversions.
668 In some drivers, you want to catch interrupts, and/or want to use the
669 <link linkend="insn-inttrig">INSN_INTTRIG</link> instruction. In this
670 case, you must provide and register these
671 <link linkend="drivercallbacks">callback</link> functions.
674 Implementation of all of the above-mentioned functions requires
675 perfect knowledge about the hardware registers and addresses of the
676 interface card. In general, you can find
677 <emphasis>some</emphasis> inspiration in the already available device
678 drivers, but don't trust that blind
679 <emphasis>cut-and-paste</emphasis> will bring you far…
684 <section id="drivercallbacks">
686 Callbacks, events and interrupts
690 Continuous acquisition is tyically an
691 <emphasis>asynchronous</emphasis> activity: the function call that
692 has set the acquisition in motion has returned before the acquisition
693 has finished (or even started). So, not only the acquired data must be
694 sent back to the user's buffer <quote>in the background</quote>, but
695 various types of asynchronous <emphasis>event handling</emphasis> can
696 be needed during the acquisition:
701 The <emphasis>hardware</emphasis> can generate some error or
708 Normal functional interrupts are generated by the hardware, e.g.,
709 signalling the filling-up of the card's hardware buffer, or the end of
710 an acquisition <link linkend="scan">scan</link>, etc.
716 The device driver writer can register a driver-supplied
717 <quote>callback</quote> function, that is called at the end of each
718 hardware interrupt routine.
724 Another driver-supplied callback function is executed when the user
725 program launches an <link linkend="insn-inttrig">INSN_INTTRIG</link>
726 instruction. This event handling is executed
727 <emphasis>synchronously</emphasis> with the execution of the
728 triggering instruction.
735 The interrupt handlers are registered through the functions mentioned
736 <link linkend="driversupportfunctions">before</link>
737 The event handling is done in the existing &comedi; drivers in
738 statements such as this one:
740 <anchor id="async-events"/>
741 s->async->events |= COMEDI_CB_EOA | COMEDI_CB_ERROR
743 It fills in the bits corresponding to particular events in the
744 <link linkend="comediasync">comedi_async</link> data structure.
745 The possible event bits are:
750 <anchor id="comedi-cb-eoa"/>
751 <parameter>COMEDI_CB_EOA</parameter>: execute the callback at the
752 <quote>End Of-Acquisition</quote>.
758 <anchor id="comedi-cb-eos"/>
759 <parameter>COMEDI_CB_EOS</parameter>: execute the callback at the
760 <quote>End-Of-Scan</quote>.
766 <anchor id="comedi-cb-overflow"/>
767 <parameter>COMEDI_CB_OVERFLOW</parameter>: execute the callback when a
768 buffer overflow has occurred.
774 <anchor id="comedi-cb-error"/>
775 <parameter>COMEDI_CB_ERROR</parameter>: execute the callback at the
776 occurrence of an (undetermined) error.
786 <section id="drivercaveats">
788 Device driver caveats
792 A few things to strive for when writing a new driver:
797 Some DAQ cards consist of different <quote>layers</quote> of hardware,
798 which can each be given their own device driver. Examples are:
799 some of the National Instruments cards, that all share the same
800 <emphasis>Mite</emphasis> PCI driver chip; the ubiquitous parallel
801 port, that can be used for simple digital IO acquisitions. If your
802 new card has such a multi-layer design too, please take the effort to
803 provide drivers for each layer separately.
809 Your hardware driver should be functional appropriate to the resources
810 allocated. I.e., if the driver is fully functional when configured
811 with an IRQ and DMA, it should still function moderately well with
812 just an IRQ, or still do minor tasks without IRQ or DMA. Does your
813 driver really require an IRQ to do digital I/O? Maybe someone will
814 want to use your driver <emphasis>just</emphasis> to do digital I/O
815 and has no interrupts available.
821 Drivers are to have absolutely <emphasis role="strong">no</emphasis>
822 global variables, mainly because the existence of global variables
823 immediately negates any possibility of using the driver for two
824 devices. The pointer <function>dev->private</function> should be used
825 to point to a structure containing any additional variables needed by
826 a driver/device combination.
832 Drivers should report errors and warnings via the
833 <function>comedi_error()</function> function.
834 (This is <emphasis>not</emphasis> the same function as the user-space
835 <link linkend="func-ref-comedi-perror">comedi_perror()</link> function.)
844 <section id="integratingdriver">
846 Integrating the driver in the &comedi; library
850 For integrating new drivers in the &comedi;'s source tree the following
851 things have to be done:
856 Choose a sensible name for the source code file. Let's assume here
857 that you call it <quote>mydriver.c</quote>
863 Put your new driver into <quote>comedi/drivers/mydriver.c</quote>.
869 Edit <quote>comedi/drivers/Makefile.am</quote> and add <quote>mydriver.ko</quote>
870 to the <quote>module_PROGRAMS</quote> list. Also add a line
872 mydriver_ko_SOURCES = mydriver.c
874 in the alphabetically appropriate place.
880 Run ./autogen.sh in the top-level comedi directory. You will
881 need to have (a recent version of) autoconf and automake
882 installed to successfully run autogen.sh. Afterwards, your driver will
883 be built along with the rest of the drivers when you 'make'.
889 If you want to have your driver included in the &comedi; distribution
890 (you <emphasis>definitely</emphasis> want to :-) ) send it to
891 David Schleef <address><email>ds@schleef.org</email></address> or
892 Frank Hess <address><email>fmhess@users.sourceforge.net</email></address>
893 for review and integration. Note your work must be licensed under terms
894 compatible with the GNU GPL to be distributed as a part of Comedi.