Merge git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-linus
[linux-2.6] / Documentation / DocBook / uio-howto.tmpl
1 <?xml version="1.0" encoding="UTF-8"?>
2 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
4
5 <book id="index">
6 <bookinfo>
7 <title>The Userspace I/O HOWTO</title>
8
9 <author>
10       <firstname>Hans-Jürgen</firstname>
11       <surname>Koch</surname>
12       <authorblurb><para>Linux developer, Linutronix</para></authorblurb>
13         <affiliation>
14         <orgname>
15                 <ulink url="http://www.linutronix.de">Linutronix</ulink>
16         </orgname>
17
18         <address>
19            <email>hjk@linutronix.de</email>
20         </address>
21     </affiliation>
22 </author>
23
24 <copyright>
25         <year>2006-2008</year>
26         <holder>Hans-Jürgen Koch.</holder>
27 </copyright>
28
29 <legalnotice>
30 <para>
31 This documentation is Free Software licensed under the terms of the
32 GPL version 2.
33 </para>
34 </legalnotice>
35
36 <pubdate>2006-12-11</pubdate>
37
38 <abstract>
39         <para>This HOWTO describes concept and usage of Linux kernel's
40                 Userspace I/O system.</para>
41 </abstract>
42
43 <revhistory>
44         <revision>
45         <revnumber>0.6</revnumber>
46         <date>2008-12-05</date>
47         <authorinitials>hjk</authorinitials>
48         <revremark>Added description of portio sysfs attributes.</revremark>
49         </revision>
50         <revision>
51         <revnumber>0.5</revnumber>
52         <date>2008-05-22</date>
53         <authorinitials>hjk</authorinitials>
54         <revremark>Added description of write() function.</revremark>
55         </revision>
56         <revision>
57         <revnumber>0.4</revnumber>
58         <date>2007-11-26</date>
59         <authorinitials>hjk</authorinitials>
60         <revremark>Removed section about uio_dummy.</revremark>
61         </revision>
62         <revision>
63         <revnumber>0.3</revnumber>
64         <date>2007-04-29</date>
65         <authorinitials>hjk</authorinitials>
66         <revremark>Added section about userspace drivers.</revremark>
67         </revision>
68         <revision>
69         <revnumber>0.2</revnumber>
70         <date>2007-02-13</date>
71         <authorinitials>hjk</authorinitials>
72         <revremark>Update after multiple mappings were added.</revremark>
73         </revision>
74         <revision>
75         <revnumber>0.1</revnumber>
76         <date>2006-12-11</date>
77         <authorinitials>hjk</authorinitials>
78         <revremark>First draft.</revremark>
79         </revision>
80 </revhistory>
81 </bookinfo>
82
83 <chapter id="aboutthisdoc">
84 <?dbhtml filename="aboutthis.html"?>
85 <title>About this document</title>
86
87 <sect1 id="translations">
88 <?dbhtml filename="translations.html"?>
89 <title>Translations</title>
90
91 <para>If you know of any translations for this document, or you are
92 interested in translating it, please email me
93 <email>hjk@linutronix.de</email>.
94 </para>
95 </sect1>
96
97 <sect1 id="preface">
98 <title>Preface</title>
99         <para>
100         For many types of devices, creating a Linux kernel driver is
101         overkill.  All that is really needed is some way to handle an
102         interrupt and provide access to the memory space of the
103         device.  The logic of controlling the device does not
104         necessarily have to be within the kernel, as the device does
105         not need to take advantage of any of other resources that the
106         kernel provides.  One such common class of devices that are
107         like this are for industrial I/O cards.
108         </para>
109         <para>
110         To address this situation, the userspace I/O system (UIO) was
111         designed.  For typical industrial I/O cards, only a very small
112         kernel module is needed. The main part of the driver will run in
113         user space. This simplifies development and reduces the risk of
114         serious bugs within a kernel module.
115         </para>
116         <para>
117         Please note that UIO is not an universal driver interface. Devices
118         that are already handled well by other kernel subsystems (like
119         networking or serial or USB) are no candidates for an UIO driver.
120         Hardware that is ideally suited for an UIO driver fulfills all of
121         the following:
122         </para>
123 <itemizedlist>
124 <listitem>
125         <para>The device has memory that can be mapped. The device can be
126         controlled completely by writing to this memory.</para>
127 </listitem>
128 <listitem>
129         <para>The device usually generates interrupts.</para>
130 </listitem>
131 <listitem>
132         <para>The device does not fit into one of the standard kernel
133         subsystems.</para>
134 </listitem>
135 </itemizedlist>
136 </sect1>
137
138 <sect1 id="thanks">
139 <title>Acknowledgments</title>
140         <para>I'd like to thank Thomas Gleixner and Benedikt Spranger of
141         Linutronix, who have not only written most of the UIO code, but also
142         helped greatly writing this HOWTO by giving me all kinds of background
143         information.</para>
144 </sect1>
145
146 <sect1 id="feedback">
147 <title>Feedback</title>
148         <para>Find something wrong with this document? (Or perhaps something
149         right?) I would love to hear from you. Please email me at
150         <email>hjk@linutronix.de</email>.</para>
151 </sect1>
152 </chapter>
153
154 <chapter id="about">
155 <?dbhtml filename="about.html"?>
156 <title>About UIO</title>
157
158 <para>If you use UIO for your card's driver, here's what you get:</para>
159
160 <itemizedlist>
161 <listitem>
162         <para>only one small kernel module to write and maintain.</para>
163 </listitem>
164 <listitem>
165         <para>develop the main part of your driver in user space,
166         with all the tools and libraries you're used to.</para>
167 </listitem>
168 <listitem>
169         <para>bugs in your driver won't crash the kernel.</para>
170 </listitem>
171 <listitem>
172         <para>updates of your driver can take place without recompiling
173         the kernel.</para>
174 </listitem>
175 </itemizedlist>
176
177 <sect1 id="how_uio_works">
178 <title>How UIO works</title>
179         <para>
180         Each UIO device is accessed through a device file and several
181         sysfs attribute files. The device file will be called
182         <filename>/dev/uio0</filename> for the first device, and
183         <filename>/dev/uio1</filename>, <filename>/dev/uio2</filename>
184         and so on for subsequent devices.
185         </para>
186
187         <para><filename>/dev/uioX</filename> is used to access the
188         address space of the card. Just use
189         <function>mmap()</function> to access registers or RAM
190         locations of your card.
191         </para>
192
193         <para>
194         Interrupts are handled by reading from
195         <filename>/dev/uioX</filename>. A blocking
196         <function>read()</function> from
197         <filename>/dev/uioX</filename> will return as soon as an
198         interrupt occurs. You can also use
199         <function>select()</function> on
200         <filename>/dev/uioX</filename> to wait for an interrupt. The
201         integer value read from <filename>/dev/uioX</filename>
202         represents the total interrupt count. You can use this number
203         to figure out if you missed some interrupts.
204         </para>
205         <para>
206         For some hardware that has more than one interrupt source internally,
207         but not separate IRQ mask and status registers, there might be
208         situations where userspace cannot determine what the interrupt source
209         was if the kernel handler disables them by writing to the chip's IRQ
210         register. In such a case, the kernel has to disable the IRQ completely
211         to leave the chip's register untouched. Now the userspace part can
212         determine the cause of the interrupt, but it cannot re-enable
213         interrupts. Another cornercase is chips where re-enabling interrupts
214         is a read-modify-write operation to a combined IRQ status/acknowledge
215         register. This would be racy if a new interrupt occurred
216         simultaneously.
217         </para>
218         <para>
219         To address these problems, UIO also implements a write() function. It
220         is normally not used and can be ignored for hardware that has only a
221         single interrupt source or has separate IRQ mask and status registers.
222         If you need it, however, a write to <filename>/dev/uioX</filename>
223         will call the <function>irqcontrol()</function> function implemented
224         by the driver. You have to write a 32-bit value that is usually either
225         0 or 1 to disable or enable interrupts. If a driver does not implement
226         <function>irqcontrol()</function>, <function>write()</function> will
227         return with <varname>-ENOSYS</varname>.
228         </para>
229
230         <para>
231         To handle interrupts properly, your custom kernel module can
232         provide its own interrupt handler. It will automatically be
233         called by the built-in handler.
234         </para>
235
236         <para>
237         For cards that don't generate interrupts but need to be
238         polled, there is the possibility to set up a timer that
239         triggers the interrupt handler at configurable time intervals.
240         This interrupt simulation is done by calling
241         <function>uio_event_notify()</function>
242         from the timer's event handler.
243         </para>
244
245         <para>
246         Each driver provides attributes that are used to read or write
247         variables. These attributes are accessible through sysfs
248         files.  A custom kernel driver module can add its own
249         attributes to the device owned by the uio driver, but not added
250         to the UIO device itself at this time.  This might change in the
251         future if it would be found to be useful.
252         </para>
253
254         <para>
255         The following standard attributes are provided by the UIO
256         framework:
257         </para>
258 <itemizedlist>
259 <listitem>
260         <para>
261         <filename>name</filename>: The name of your device. It is
262         recommended to use the name of your kernel module for this.
263         </para>
264 </listitem>
265 <listitem>
266         <para>
267         <filename>version</filename>: A version string defined by your
268         driver. This allows the user space part of your driver to deal
269         with different versions of the kernel module.
270         </para>
271 </listitem>
272 <listitem>
273         <para>
274         <filename>event</filename>: The total number of interrupts
275         handled by the driver since the last time the device node was
276         read.
277         </para>
278 </listitem>
279 </itemizedlist>
280 <para>
281         These attributes appear under the
282         <filename>/sys/class/uio/uioX</filename> directory.  Please
283         note that this directory might be a symlink, and not a real
284         directory.  Any userspace code that accesses it must be able
285         to handle this.
286 </para>
287 <para>
288         Each UIO device can make one or more memory regions available for
289         memory mapping. This is necessary because some industrial I/O cards
290         require access to more than one PCI memory region in a driver.
291 </para>
292 <para>
293         Each mapping has its own directory in sysfs, the first mapping
294         appears as <filename>/sys/class/uio/uioX/maps/map0/</filename>.
295         Subsequent mappings create directories <filename>map1/</filename>,
296         <filename>map2/</filename>, and so on. These directories will only
297         appear if the size of the mapping is not 0.
298 </para>
299 <para>
300         Each <filename>mapX/</filename> directory contains two read-only files
301         that show start address and size of the memory:
302 </para>
303 <itemizedlist>
304 <listitem>
305         <para>
306         <filename>addr</filename>: The address of memory that can be mapped.
307         </para>
308 </listitem>
309 <listitem>
310         <para>
311         <filename>size</filename>: The size, in bytes, of the memory
312         pointed to by addr.
313         </para>
314 </listitem>
315 </itemizedlist>
316
317 <para>
318         From userspace, the different mappings are distinguished by adjusting
319         the <varname>offset</varname> parameter of the
320         <function>mmap()</function> call. To map the memory of mapping N, you
321         have to use N times the page size as your offset:
322 </para>
323 <programlisting format="linespecific">
324 offset = N * getpagesize();
325 </programlisting>
326
327 <para>
328         Sometimes there is hardware with memory-like regions that can not be
329         mapped with the technique described here, but there are still ways to
330         access them from userspace. The most common example are x86 ioports.
331         On x86 systems, userspace can access these ioports using
332         <function>ioperm()</function>, <function>iopl()</function>,
333         <function>inb()</function>, <function>outb()</function>, and similar
334         functions.
335 </para>
336 <para>
337         Since these ioport regions can not be mapped, they will not appear under
338         <filename>/sys/class/uio/uioX/maps/</filename> like the normal memory
339         described above. Without information about the port regions a hardware
340         has to offer, it becomes difficult for the userspace part of the
341         driver to find out which ports belong to which UIO device.
342 </para>
343 <para>
344         To address this situation, the new directory
345         <filename>/sys/class/uio/uioX/portio/</filename> was added. It only
346         exists if the driver wants to pass information about one or more port
347         regions to userspace. If that is the case, subdirectories named
348         <filename>port0</filename>, <filename>port1</filename>, and so on,
349         will appear underneath
350         <filename>/sys/class/uio/uioX/portio/</filename>.
351 </para>
352 <para>
353         Each <filename>portX/</filename> directory contains three read-only
354         files that show start, size, and type of the port region:
355 </para>
356 <itemizedlist>
357 <listitem>
358         <para>
359         <filename>start</filename>: The first port of this region.
360         </para>
361 </listitem>
362 <listitem>
363         <para>
364         <filename>size</filename>: The number of ports in this region.
365         </para>
366 </listitem>
367 <listitem>
368         <para>
369         <filename>porttype</filename>: A string describing the type of port.
370         </para>
371 </listitem>
372 </itemizedlist>
373
374
375 </sect1>
376 </chapter>
377
378 <chapter id="custom_kernel_module" xreflabel="Writing your own kernel module">
379 <?dbhtml filename="custom_kernel_module.html"?>
380 <title>Writing your own kernel module</title>
381         <para>
382         Please have a look at <filename>uio_cif.c</filename> as an
383         example. The following paragraphs explain the different
384         sections of this file.
385         </para>
386
387 <sect1 id="uio_info">
388 <title>struct uio_info</title>
389         <para>
390         This structure tells the framework the details of your driver,
391         Some of the members are required, others are optional.
392         </para>
393
394 <itemizedlist>
395 <listitem><para>
396 <varname>const char *name</varname>: Required. The name of your driver as
397 it will appear in sysfs. I recommend using the name of your module for this.
398 </para></listitem>
399
400 <listitem><para>
401 <varname>const char *version</varname>: Required. This string appears in
402 <filename>/sys/class/uio/uioX/version</filename>.
403 </para></listitem>
404
405 <listitem><para>
406 <varname>struct uio_mem mem[ MAX_UIO_MAPS ]</varname>: Required if you
407 have memory that can be mapped with <function>mmap()</function>. For each
408 mapping you need to fill one of the <varname>uio_mem</varname> structures.
409 See the description below for details.
410 </para></listitem>
411
412 <listitem><para>
413 <varname>struct uio_port port[ MAX_UIO_PORTS_REGIONS ]</varname>: Required
414 if you want to pass information about ioports to userspace. For each port
415 region you need to fill one of the <varname>uio_port</varname> structures.
416 See the description below for details.
417 </para></listitem>
418
419 <listitem><para>
420 <varname>long irq</varname>: Required. If your hardware generates an
421 interrupt, it's your modules task to determine the irq number during
422 initialization. If you don't have a hardware generated interrupt but
423 want to trigger the interrupt handler in some other way, set
424 <varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>.
425 If you had no interrupt at all, you could set
426 <varname>irq</varname> to <varname>UIO_IRQ_NONE</varname>, though this
427 rarely makes sense.
428 </para></listitem>
429
430 <listitem><para>
431 <varname>unsigned long irq_flags</varname>: Required if you've set
432 <varname>irq</varname> to a hardware interrupt number. The flags given
433 here will be used in the call to <function>request_irq()</function>.
434 </para></listitem>
435
436 <listitem><para>
437 <varname>int (*mmap)(struct uio_info *info, struct vm_area_struct
438 *vma)</varname>: Optional. If you need a special
439 <function>mmap()</function> function, you can set it here. If this
440 pointer is not NULL, your <function>mmap()</function> will be called
441 instead of the built-in one.
442 </para></listitem>
443
444 <listitem><para>
445 <varname>int (*open)(struct uio_info *info, struct inode *inode)
446 </varname>: Optional. You might want to have your own
447 <function>open()</function>, e.g. to enable interrupts only when your
448 device is actually used.
449 </para></listitem>
450
451 <listitem><para>
452 <varname>int (*release)(struct uio_info *info, struct inode *inode)
453 </varname>: Optional. If you define your own
454 <function>open()</function>, you will probably also want a custom
455 <function>release()</function> function.
456 </para></listitem>
457
458 <listitem><para>
459 <varname>int (*irqcontrol)(struct uio_info *info, s32 irq_on)
460 </varname>: Optional. If you need to be able to enable or disable
461 interrupts from userspace by writing to <filename>/dev/uioX</filename>,
462 you can implement this function. The parameter <varname>irq_on</varname>
463 will be 0 to disable interrupts and 1 to enable them.
464 </para></listitem>
465 </itemizedlist>
466
467 <para>
468 Usually, your device will have one or more memory regions that can be mapped
469 to user space. For each region, you have to set up a
470 <varname>struct uio_mem</varname> in the <varname>mem[]</varname> array.
471 Here's a description of the fields of <varname>struct uio_mem</varname>:
472 </para>
473
474 <itemizedlist>
475 <listitem><para>
476 <varname>int memtype</varname>: Required if the mapping is used. Set this to
477 <varname>UIO_MEM_PHYS</varname> if you you have physical memory on your
478 card to be mapped. Use <varname>UIO_MEM_LOGICAL</varname> for logical
479 memory (e.g. allocated with <function>kmalloc()</function>). There's also
480 <varname>UIO_MEM_VIRTUAL</varname> for virtual memory.
481 </para></listitem>
482
483 <listitem><para>
484 <varname>unsigned long addr</varname>: Required if the mapping is used.
485 Fill in the address of your memory block. This address is the one that
486 appears in sysfs.
487 </para></listitem>
488
489 <listitem><para>
490 <varname>unsigned long size</varname>: Fill in the size of the
491 memory block that <varname>addr</varname> points to. If <varname>size</varname>
492 is zero, the mapping is considered unused. Note that you
493 <emphasis>must</emphasis> initialize <varname>size</varname> with zero for
494 all unused mappings.
495 </para></listitem>
496
497 <listitem><para>
498 <varname>void *internal_addr</varname>: If you have to access this memory
499 region from within your kernel module, you will want to map it internally by
500 using something like <function>ioremap()</function>. Addresses
501 returned by this function cannot be mapped to user space, so you must not
502 store it in <varname>addr</varname>. Use <varname>internal_addr</varname>
503 instead to remember such an address.
504 </para></listitem>
505 </itemizedlist>
506
507 <para>
508 Please do not touch the <varname>kobj</varname> element of
509 <varname>struct uio_mem</varname>! It is used by the UIO framework
510 to set up sysfs files for this mapping. Simply leave it alone.
511 </para>
512
513 <para>
514 Sometimes, your device can have one or more port regions which can not be
515 mapped to userspace. But if there are other possibilities for userspace to
516 access these ports, it makes sense to make information about the ports
517 available in sysfs. For each region, you have to set up a
518 <varname>struct uio_port</varname> in the <varname>port[]</varname> array.
519 Here's a description of the fields of <varname>struct uio_port</varname>:
520 </para>
521
522 <itemizedlist>
523 <listitem><para>
524 <varname>char *porttype</varname>: Required. Set this to one of the predefined
525 constants. Use <varname>UIO_PORT_X86</varname> for the ioports found in x86
526 architectures.
527 </para></listitem>
528
529 <listitem><para>
530 <varname>unsigned long start</varname>: Required if the port region is used.
531 Fill in the number of the first port of this region.
532 </para></listitem>
533
534 <listitem><para>
535 <varname>unsigned long size</varname>: Fill in the number of ports in this
536 region. If <varname>size</varname> is zero, the region is considered unused.
537 Note that you <emphasis>must</emphasis> initialize <varname>size</varname>
538 with zero for all unused regions.
539 </para></listitem>
540 </itemizedlist>
541
542 <para>
543 Please do not touch the <varname>portio</varname> element of
544 <varname>struct uio_port</varname>! It is used internally by the UIO
545 framework to set up sysfs files for this region. Simply leave it alone.
546 </para>
547
548 </sect1>
549
550 <sect1 id="adding_irq_handler">
551 <title>Adding an interrupt handler</title>
552         <para>
553         What you need to do in your interrupt handler depends on your
554         hardware and on how you want to handle it. You should try to
555         keep the amount of code in your kernel interrupt handler low.
556         If your hardware requires no action that you
557         <emphasis>have</emphasis> to perform after each interrupt,
558         then your handler can be empty.</para> <para>If, on the other
559         hand, your hardware <emphasis>needs</emphasis> some action to
560         be performed after each interrupt, then you
561         <emphasis>must</emphasis> do it in your kernel module. Note
562         that you cannot rely on the userspace part of your driver. Your
563         userspace program can terminate at any time, possibly leaving
564         your hardware in a state where proper interrupt handling is
565         still required.
566         </para>
567
568         <para>
569         There might also be applications where you want to read data
570         from your hardware at each interrupt and buffer it in a piece
571         of kernel memory you've allocated for that purpose.  With this
572         technique you could avoid loss of data if your userspace
573         program misses an interrupt.
574         </para>
575
576         <para>
577         A note on shared interrupts: Your driver should support
578         interrupt sharing whenever this is possible. It is possible if
579         and only if your driver can detect whether your hardware has
580         triggered the interrupt or not. This is usually done by looking
581         at an interrupt status register. If your driver sees that the
582         IRQ bit is actually set, it will perform its actions, and the
583         handler returns IRQ_HANDLED. If the driver detects that it was
584         not your hardware that caused the interrupt, it will do nothing
585         and return IRQ_NONE, allowing the kernel to call the next
586         possible interrupt handler.
587         </para>
588
589         <para>
590         If you decide not to support shared interrupts, your card
591         won't work in computers with no free interrupts. As this
592         frequently happens on the PC platform, you can save yourself a
593         lot of trouble by supporting interrupt sharing.
594         </para>
595 </sect1>
596
597 </chapter>
598
599 <chapter id="userspace_driver" xreflabel="Writing a driver in user space">
600 <?dbhtml filename="userspace_driver.html"?>
601 <title>Writing a driver in userspace</title>
602         <para>
603         Once you have a working kernel module for your hardware, you can
604         write the userspace part of your driver. You don't need any special
605         libraries, your driver can be written in any reasonable language,
606         you can use floating point numbers and so on. In short, you can
607         use all the tools and libraries you'd normally use for writing a
608         userspace application.
609         </para>
610
611 <sect1 id="getting_uio_information">
612 <title>Getting information about your UIO device</title>
613         <para>
614         Information about all UIO devices is available in sysfs. The
615         first thing you should do in your driver is check
616         <varname>name</varname> and <varname>version</varname> to
617         make sure your talking to the right device and that its kernel
618         driver has the version you expect.
619         </para>
620         <para>
621         You should also make sure that the memory mapping you need
622         exists and has the size you expect.
623         </para>
624         <para>
625         There is a tool called <varname>lsuio</varname> that lists
626         UIO devices and their attributes. It is available here:
627         </para>
628         <para>
629         <ulink url="http://www.osadl.org/projects/downloads/UIO/user/">
630                 http://www.osadl.org/projects/downloads/UIO/user/</ulink>
631         </para>
632         <para>
633         With <varname>lsuio</varname> you can quickly check if your
634         kernel module is loaded and which attributes it exports.
635         Have a look at the manpage for details.
636         </para>
637         <para>
638         The source code of <varname>lsuio</varname> can serve as an
639         example for getting information about an UIO device.
640         The file <filename>uio_helper.c</filename> contains a lot of
641         functions you could use in your userspace driver code.
642         </para>
643 </sect1>
644
645 <sect1 id="mmap_device_memory">
646 <title>mmap() device memory</title>
647         <para>
648         After you made sure you've got the right device with the
649         memory mappings you need, all you have to do is to call
650         <function>mmap()</function> to map the device's memory
651         to userspace.
652         </para>
653         <para>
654         The parameter <varname>offset</varname> of the
655         <function>mmap()</function> call has a special meaning
656         for UIO devices: It is used to select which mapping of
657         your device you want to map. To map the memory of
658         mapping N, you have to use N times the page size as
659         your offset:
660         </para>
661 <programlisting format="linespecific">
662         offset = N * getpagesize();
663 </programlisting>
664         <para>
665         N starts from zero, so if you've got only one memory
666         range to map, set <varname>offset = 0</varname>.
667         A drawback of this technique is that memory is always
668         mapped beginning with its start address.
669         </para>
670 </sect1>
671
672 <sect1 id="wait_for_interrupts">
673 <title>Waiting for interrupts</title>
674         <para>
675         After you successfully mapped your devices memory, you
676         can access it like an ordinary array. Usually, you will
677         perform some initialization. After that, your hardware
678         starts working and will generate an interrupt as soon
679         as it's finished, has some data available, or needs your
680         attention because an error occured.
681         </para>
682         <para>
683         <filename>/dev/uioX</filename> is a read-only file. A
684         <function>read()</function> will always block until an
685         interrupt occurs. There is only one legal value for the
686         <varname>count</varname> parameter of
687         <function>read()</function>, and that is the size of a
688         signed 32 bit integer (4). Any other value for
689         <varname>count</varname> causes <function>read()</function>
690         to fail. The signed 32 bit integer read is the interrupt
691         count of your device. If the value is one more than the value
692         you read the last time, everything is OK. If the difference
693         is greater than one, you missed interrupts.
694         </para>
695         <para>
696         You can also use <function>select()</function> on
697         <filename>/dev/uioX</filename>.
698         </para>
699 </sect1>
700
701 </chapter>
702
703 <appendix id="app1">
704 <title>Further information</title>
705 <itemizedlist>
706         <listitem><para>
707                         <ulink url="http://www.osadl.org">
708                                 OSADL homepage.</ulink>
709                 </para></listitem>
710         <listitem><para>
711                 <ulink url="http://www.linutronix.de">
712                  Linutronix homepage.</ulink>
713                 </para></listitem>
714 </itemizedlist>
715 </appendix>
716
717 </book>