| <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[]> |
| <book id="LinuxKernelAPI"> |
| <bookinfo> |
| <title>The Linux Kernel API</title> |
| |
| <legalnotice> |
| <para> |
| This documentation is free software; you can redistribute |
| it and/or modify it under the terms of the GNU General Public |
| License as published by the Free Software Foundation; either |
| version 2 of the License, or (at your option) any later |
| version. |
| </para> |
| |
| <para> |
| This program is distributed in the hope that it will be |
| useful, but WITHOUT ANY WARRANTY; without even the implied |
| warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
| See the GNU General Public License for more details. |
| </para> |
| |
| <para> |
| You should have received a copy of the GNU General Public |
| License along with this program; if not, write to the Free |
| Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, |
| MA 02111-1307 USA |
| </para> |
| |
| <para> |
| For more details see the file COPYING in the source |
| distribution of Linux. |
| </para> |
| </legalnotice> |
| </bookinfo> |
| |
| <toc></toc> |
| |
| <chapter id="Basics"> |
| <title>Driver Basics</title> |
| <sect1><title>Driver Entry and Exit points</title> |
| !Iinclude/linux/init.h |
| </sect1> |
| |
| <sect1><title>Atomic and pointer manipulation</title> |
| !Iinclude/asm-i386/atomic.h |
| !Iinclude/asm-i386/unaligned.h |
| </sect1> |
| |
| <sect1><title>Delaying, scheduling, and timer routines</title> |
| !Ekernel/sched.c |
| </sect1> |
| </chapter> |
| |
| <chapter id="adt"> |
| <title>Data Types</title> |
| <sect1><title>Doubly Linked Lists</title> |
| !Iinclude/linux/list.h |
| </sect1> |
| </chapter> |
| |
| <chapter id="libc"> |
| <title>Basic C Library Functions</title> |
| |
| <para> |
| When writing drivers, you cannot in general use routines which are |
| from the C Library. Some of the functions have been found generally |
| useful and they are listed below. The behaviour of these functions |
| may vary slightly from those defined by ANSI, and these deviations |
| are noted in the text. |
| </para> |
| |
| <sect1><title>String Conversions</title> |
| !Ilib/vsprintf.c |
| !Elib/vsprintf.c |
| </sect1> |
| <sect1><title>String Manipulation</title> |
| !Ilib/string.c |
| </sect1> |
| <sect1><title>Bit Operations</title> |
| !Iinclude/asm-i386/bitops.h |
| </sect1> |
| </chapter> |
| |
| <chapter id="mm"> |
| <title>Memory Management in Linux</title> |
| <sect1><title>The Slab Cache</title> |
| !Emm/slab.c |
| </sect1> |
| </chapter> |
| |
| <chapter id="proc"> |
| <title>The proc filesystem</title> |
| |
| <sect1><title>sysctl interface</title> |
| !Ekernel/sysctl.c |
| </sect1> |
| </chapter> |
| |
| <chapter id="vfs"> |
| <title>The Linux VFS</title> |
| <sect1><title>The Directory Cache</title> |
| !Efs/dcache.c |
| !Iinclude/linux/dcache.h |
| </sect1> |
| <sect1><title>Inode Handling</title> |
| !Efs/inode.c |
| !Efs/bad_inode.c |
| </sect1> |
| <sect1><title>Registration and Superblocks</title> |
| !Efs/super.c |
| </sect1> |
| <sect1><title>File Locks</title> |
| !Efs/locks.c |
| !Ifs/locks.c |
| </sect1> |
| </chapter> |
| |
| <chapter id="netcore"> |
| <title>Linux Networking</title> |
| <sect1><title>Socket Buffer Functions</title> |
| !Iinclude/linux/skbuff.h |
| !Enet/core/skbuff.c |
| </sect1> |
| <sect1><title>Socket Filter</title> |
| !Enet/core/filter.c |
| </sect1> |
| </chapter> |
| |
| <chapter id="netdev"> |
| <title>Network device support</title> |
| <sect1><title>Driver Support</title> |
| !Edrivers/net/net_init.c |
| !Enet/core/dev.c |
| </sect1> |
| <sect1><title>8390 Based Network Cards</title> |
| !Edrivers/net/8390.c |
| </sect1> |
| <sect1><title>Synchronous PPP</title> |
| !Edrivers/net/wan/syncppp.c |
| </sect1> |
| </chapter> |
| |
| <chapter id="modload"> |
| <title>Module Support</title> |
| <sect1><title>Module Loading</title> |
| !Ekernel/kmod.c |
| </sect1> |
| <sect1><title>Inter Module support</title> |
| !Ekernel/module.c |
| </sect1> |
| </chapter> |
| |
| <chapter id="hardware"> |
| <title>Hardware Interfaces</title> |
| <sect1><title>Interrupt Handling</title> |
| !Iarch/i386/kernel/irq.c |
| </sect1> |
| |
| <sect1><title>MTRR Handling</title> |
| !Earch/i386/kernel/mtrr.c |
| </sect1> |
| <sect1><title>PCI Support Library</title> |
| !Edrivers/pci/pci.c |
| </sect1> |
| <sect1><title>PCI Hotplug Support Library</title> |
| !Edrivers/hotplug/pci_hotplug_core.c |
| !Edrivers/hotplug/pci_hotplug_util.c |
| </sect1> |
| <sect1><title>MCA Architecture</title> |
| <sect2><title>MCA Device Functions</title> |
| !Earch/i386/kernel/mca.c |
| </sect2> |
| <sect2><title>MCA Bus DMA</title> |
| !Iinclude/asm-i386/mca_dma.h |
| </sect2> |
| </sect1> |
| </chapter> |
| |
| <chapter id="devfs"> |
| <title>The Device File System</title> |
| !Efs/devfs/base.c |
| </chapter> |
| |
| <chapter id="pmfuncs"> |
| <title>Power Management</title> |
| !Ekernel/pm.c |
| </chapter> |
| |
| <chapter id="blkdev"> |
| <title>Block Devices</title> |
| !Edrivers/block/ll_rw_blk.c |
| </chapter> |
| |
| <chapter id="miscdev"> |
| <title>Miscellaneous Devices</title> |
| !Edrivers/char/misc.c |
| </chapter> |
| |
| <chapter id="viddev"> |
| <title>Video4Linux</title> |
| !Edrivers/media/video/videodev.c |
| </chapter> |
| |
| <chapter id="snddev"> |
| <title>Sound Devices</title> |
| !Esound/sound_core.c |
| !Isound/sound_firmware.c |
| </chapter> |
| |
| <chapter id="usb"> |
| <title>USB Devices</title> |
| |
| <para>Drivers for USB devices talk to the "usbcore" APIs, and are |
| exposed through driver frameworks such as block, character, |
| or network devices. |
| There are two types of public "usbcore" APIs: those intended for |
| general driver use, and those which are only public to drivers that |
| are part of the core. |
| The drivers that are part of the core are involved in managing a USB bus. |
| They include the "hub" driver, which manages trees of USB devices, and |
| several different kinds of "host controller" driver (HCD), which control |
| individual busses. |
| </para> |
| |
| <para>The device model seen by USB drivers is relatively complex. |
| </para> |
| |
| <itemizedlist> |
| |
| <listitem><para>USB supports four kinds of data transfer |
| (control, bulk, interrupt, and isochronous). Two transfer |
| types use bandwidth as it's available (control and bulk), |
| while the other two types of transfer (interrupt and isochronous) |
| are scheduled to provide guaranteed bandwidth. |
| </para></listitem> |
| |
| <listitem><para>The device description model includes one or more |
| "configurations" per device, only one of which is active at a time. |
| </para></listitem> |
| |
| <listitem><para>Configurations have one or more "interface", each |
| of which may have "alternate settings". Interfaces may be |
| standardized by USB "Class" specifications, or may be specific to |
| a vendor or device.</para> |
| |
| <para>USB device drivers actually bind to interfaces, not devices. |
| Think of them as "interface drivers", though you |
| may not see many devices where the distinction is important. |
| Most USB devices are simple, with only one configuration, |
| one interface, and one alternate setting. |
| </para></listitem> |
| |
| <listitem><para>Interfaces have one or more "endpoints", each of |
| which supports one type and direction of data transfer such as |
| "bulk out" or "interrupt in". The entire configuration may have |
| up to sixteen endpoints in each direction, allocated as needed |
| among all the interfaces. |
| </para></listitem> |
| |
| <listitem><para>Data transfer on USB is packetized; each endpoint |
| has a maximum packet size. |
| Drivers must often be aware of conventions such as flagging the end |
| of bulk transfers using "short" (including zero length) packets. |
| </para></listitem> |
| |
| <listitem><para>The Linux USB API supports synchronous calls for |
| control and bulk messaging. |
| It also supports asynchnous calls for all kinds of data transfer, |
| using request structures called "URBs" (USB Request Blocks). |
| </para></listitem> |
| |
| </itemizedlist> |
| |
| <para>Accordingly, the USB Core API exposed to device drivers |
| covers quite a lot of territory. You'll probably need to consult |
| the USB 2.0 specification, available online from www.usb.org at |
| no cost, as well as class or device specifications. |
| </para> |
| |
| <sect1><title>Data Types and Macros</title> |
| !Iinclude/linux/usb.h |
| </sect1> |
| |
| <sect1><title>USB Core APIs</title> |
| !Edrivers/usb/usb.c |
| </sect1> |
| |
| <sect1><title>Host Controller APIs</title> |
| <para>These APIs are only for use by host controller drivers, |
| most of which implement standard register interfaces such as |
| EHCI, OHCI, or UHCI. |
| </para> |
| !Edrivers/usb/hcd.c |
| </sect1> |
| |
| </chapter> |
| |
| <chapter id="uart16x50"> |
| <title>16x50 UART Driver</title> |
| !Edrivers/char/serial.c |
| </chapter> |
| |
| <chapter id="z85230"> |
| <title>Z85230 Support Library</title> |
| !Edrivers/net/wan/z85230.c |
| </chapter> |
| |
| <chapter id="fbdev"> |
| <title>Frame Buffer Library</title> |
| |
| <para> |
| The frame buffer drivers depend heavily on four data structures. |
| These structures are declared in include/linux/fb.h. They are |
| fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. |
| The last three can be made available to and from userland. |
| </para> |
| |
| <para> |
| fb_info defines the current state of a particular video card. |
| Inside fb_info, there exists a fb_ops structure which is a |
| collection of needed functions to make fbdev and fbcon work. |
| fb_info is only visible to the kernel. |
| </para> |
| |
| <para> |
| fb_var_screeninfo is used to describe the features of a video card |
| that are user defined. With fb_var_screeninfo, things such as |
| depth and the resolution may be defined. |
| </para> |
| |
| <para> |
| The next structure is fb_fix_screeninfo. This defines the |
| properties of a card that are created when a mode is set and can't |
| be changed otherwise. A good example of this is the start of the |
| frame buffer memory. This "locks" the address of the frame buffer |
| memory, so that it cannot be changed or moved. |
| </para> |
| |
| <para> |
| The last structure is fb_monospecs. In the old API, there was |
| little importance for fb_monospecs. This allowed for forbidden things |
| such as setting a mode of 800x600 on a fix frequency monitor. With |
| the new API, fb_monospecs prevents such things, and if used |
| correctly, can prevent a monitor from being cooked. fb_monospecs |
| will not be useful until kernels 2.5.x. |
| </para> |
| |
| <sect1><title>Frame Buffer Memory</title> |
| !Edrivers/video/fbmem.c |
| </sect1> |
| <sect1><title>Frame Buffer Console</title> |
| !Edrivers/video/fbcon.c |
| </sect1> |
| <sect1><title>Frame Buffer Colormap</title> |
| !Edrivers/video/fbcmap.c |
| </sect1> |
| <sect1><title>Frame Buffer Generic Functions</title> |
| !Idrivers/video/fbgen.c |
| </sect1> |
| <sect1><title>Frame Buffer Video Mode Database</title> |
| !Idrivers/video/modedb.c |
| !Edrivers/video/modedb.c |
| </sect1> |
| <sect1><title>Frame Buffer Macintosh Video Mode Database</title> |
| !Idrivers/video/macmodes.c |
| </sect1> |
| <sect1><title>Frame Buffer Fonts</title> |
| !Idrivers/video/fonts.c |
| </sect1> |
| </chapter> |
| |
| </book> |