rhl53.htm

linux的初学电子书

<P>The functions the device driver must perform are dependent on the nature of the device. All devices have an open() and close() routine that allows the device to perform I/O.

<BR>

<BR>

<A NAME="E69E529"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Opening the Device</B></FONT></CENTER></H4>

<BR>

<P>The open() routine must check to ensure a valid device has been specified, validate the device request (permission to access the device or device not ready), then initialize the device. The open() routine is run every time a process uses the device.

<BR>

<P>The open() routine presented here is for a generic terminal device, td.

<BR>

<PRE>

<FONT COLOR="#000080">tdopen(device,flag)

int device,flag;

{

/* definitions for local variables ignored */

/* details and definitions ignored in code */

/* check device number */

if (UNMODEM(device) &gt;= NTDEVS)

{

seterror(ENXIO);

return;

}

/* check if device in use */

/* if so, see if superuser (suser) for override */

tp = &amp;td_tty[UNMODEM(device)];

address = td_address[UNMODEM(device)];

if((tp-&gt;t_lflag &amp; XCLUDE) &amp;&amp; !suser())

{

seterror(EBBUSY);

return;

}

/* if not open, initialize by calling ttinit() */

if((tp-&gt;t_state &amp; (ISOPEN|WOPEN)) == 0)

{

ttinit(tp);

/* initialize flags, and call tdparam() to set line */

tdparam(device);

}

/* if a modem is used, check carrier status */

/* if direct, set carrier detect flags */

/* set interrupt priority to avoid overwrite */

/* wait for carrier detect signal */

/* code eliminated from example */</FONT></PRE>

<BR>

<A NAME="E69E530"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Closing the Device</B></FONT></CENTER></H4>

<BR>

<P>The close() routine is used only after the process is finished with the device. The routine disables interrupts from the device and issues any shut-down commands. All internal references to the device will be reset. close() routines are not usually 
required in many device drivers because the device is treated as being available throughout. Exceptions are removable media and exclusive-use devices. Some modems require closing (close()) to allow the line to be hung up.

<BR>

<P>Again, the terminal device example is used for the close() routine sample:

<BR>

<PRE>

<FONT COLOR="#000080">tdclose(device)

{

register struct tty *tp;

tp = &amp;td_tty[UNMODEM(device)];

(*linesw[tp-&gt;t_line].l_close)(tp);

if(tp-&gt;t_cflag &amp; HUPCL)

tdmodem(device,TURNOFF);

/* turn off exclusive flag bit */

ip-&gt;t_lflag &amp; =~XCLUDE

}</FONT></PRE>

<BR>

<A NAME="E69E531"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Strategy Functions</B></FONT></CENTER></H4>

<BR>

<P>Strategy functions (block mode devices only) are issued with a parameter to the kernel buffer header. The buffer header contains the instructions for a read or write along with a memory location for the operation to occur to or from. The size of the 
buffer is usually fixed at installation and varies from 512 to 1024 bytes. It can be examined in the file param.h as the BSIZE variable. A device's block size may be smaller than the buffer block size, in which case, the driver executes multiple reads or 
writes.

<BR>

<P>The strategy function can be illustrated in a sample device driver for a hard disk. No code is supplied, but the skeleton explains the functions of the device driver in order:

<BR>

<PRE>

<FONT COLOR="#000080">int hdstrategy(bp)

register struct buf *bp;

{

/* initialize drive and partition numbers */

/* set local variables */

/* check for valid drive &amp; partition */

/* compute target cylinder */

/* disable interrupts */

/* push request into the queue */

/* check controller: if not active, start it */

/* reset interrupt level */

}</FONT></PRE>

<BR>

<A NAME="E69E532"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Write Functions</B></FONT></CENTER></H4>

<BR>

<P>Character mode devices employ a write() instruction that checks the arguments of the instruction for validity, and then copies the data from the process memory to the device driver buffer. When all data is copied, or the buffer is full, I/O is initiated 
to the device until the buffer is empty, at which point the process is repeated. Data is read from the process memory using a simple function (cpass) that returns a -1 when end of memory is reached. The data is written to process memory using a 
complementary function (passc). The write() routine is illustrated for the terminal device:

<BR>

<PRE>

<FONT COLOR="#000080">tdwrite(device)

{

register struct tty *tp;

tp=&amp;td_tty[UNMODEM(device)];

(*linesw[tp-&gt;t_line].l_write)(tp);

}</FONT></PRE>

<P>Large amounts of data are handled by a process called copyio which takes the addresses of source and destination, a byte count, and a status flag as arguments.

<BR>

<BR>

<A NAME="E69E533"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Read Functions</B></FONT></CENTER></H4>

<BR>

<P>The read() operation for character mode devices transfers data from the device to the process memory. The operation is analogous to that of the write procedure. For the terminal device, the read() code becomes:

<BR>

<PRE>

<FONT COLOR="#000080">tdread(device)

{

register struct tty *tp;

tp=&amp;td_tty[UNMODEM(device)];

(*linesw[tp-&gt;t_line].l_read)(tp);

}</FONT></PRE>

<P>A small buffer is used when several characters are to be copied at once by read() or write(), rather than continually copying single characters. clist implements a small buffer used by character mode devices as a series of linked lists that use getc and 
putc to move characters on and off the buffer respectively. A header for clist maintains a count of the contents.

<BR>

<BR>

<A NAME="E69E534"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>start</B><B> and </B><B>ioctl </B><B>Routines</B></FONT></CENTER></H4>

<BR>

<P>A start routine is usually used for both block and character mode devices. It takes requests or data from device queues and sends them in order to the device. Block mode devices queue data with the strategy routine, while character mode devices use 
clist. The start routine maintains busy flags automatically as instructions are passed to the device. When a device has finished its process, it executes an intr routine which reinitializes the device for the next process.

<BR>

<P>The character mode ioctl() routine provides a special series of instructions to drivers. These include changes in the communications method between the driver and the operating system, as well as device-dependent operations (tape load or rewind, or 
memory allocation, for example).

<BR>

<P>The ioctl() function can be illustrated with the terminal device example. The ioctl() routine, in this case, calls another function that sets the device parameters. No code is supplied for the called function, but the skeleton explains the process of 
the device driver in order:

<BR>

<PRE>

<FONT COLOR="#000080">tdioctl(device,cmd,arg,mode) int device;

int cmd;

int mode;

faddr_t arg;

{

if(ttiocom(&amp;td_tty[UNMODEM(device)],cmd,arg,mode))

tdparam(device)

}

tdparam(device)

{

/* initialize variables */

/* get address and flags for referenced line */

addr=td_addr[UNMODEM(device)];

cflag=td_tty[UNMODEM(device].t_cflag;

/* check speed: if zero hang up line */

/* set up speed change */

/* set up line control */

/* manage interrupts */

}</FONT></PRE>

<BR>

<A NAME="E68E413"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Using a New Device Driver</B></FONT></CENTER></H3>

<BR>

<P>Drivers are added to Linux systems in a series of steps. First the interrupt handler is identified, and then the device driver entry points (such as open) are added to a driver entry point table. The entire driver is compiled and linked to the kernel, 
and then placed in the /dev directory. (See <A HREF="rhl52.htm" tppabs="http://202.113.16.101/%7eeb%7e/Red%20Hat%20Linux%20Unleashed/rhl52.htm">Chapter 52</A>, &quot;Working with the Kernel,&quot; for more information on adding to the Linux kernel.) Finally, the system is rebooted and the device driver tested. Obviously, changes to 
the driver require the process to be repeated, so device driver debugging is an art that minimizes the number of machine reboots!

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE>Two basic don'ts are important for device driver programming. Don't use sleep() or seterror() during interrupt suspensions, and don't use floating-point operations.

<BR>Interrupt suspensions must be minimized, but they must be used to avoid corruption of clist (or other buffer) data. Finally, it is important to minimize stack space.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>You can simplify debugging device drivers in many cases by using judicious printf or getchar statements to another device, such as the console. Statements like printf and getchar enable you to set up code that traces the execution steps of the device 
driver. If you are testing the device when logged in as root, the adb debugger can be used to allow examination of the kernel's memory while the device driver executes. Careful use of adb allows direct testing of minor changes in variables or addresses, 
but be careful as incorrect use of adb may result in system crashes!

<BR>

<P>One of the most common problems with device drivers (other than faulty coding) is the loss of interrupts or the suspension of a device while an interrupt is pending. This causes the device to hang. A time-out routine is included in most device drivers 
to prevent this. Typically, if an interrupt is expected and has not been received within a specified amount of time, the device is checked directly to ensure the interrupt was not missed. If an interrupt was missed, it can be simulated by code. You can use 
the spl functions during debugging usually helps to isolate these problems.

<BR>

<P>Block mode-based device drivers are generally written using interrupts. However, more programmers are now using polling for character mode devices. Polling means the device driver checks at frequent intervals to determine the device's status. The device 
driver doesn't wait for interrupts but this does add to the CPU overhead the process requires. Polling is not suitable for many devices, such as mass storage systems, but for character mode devices it can be of benefit. Serial devices generally are polled 
to save interrupt overhead.

<BR>

<P>A 19,200 baud terminal will cause approximately 1,920 interrupts per second, causing the operating system to interrupt and enter the device driver that many times. By replacing the interrupt routines with polling routines, the interval between CPU 
demands can be decreased by an order of magnitude, using a small device buffer to hold intermediate characters generated to or from the device. Real time devices also benefit from polling, since the number of interrupts does not overwhelm the CPU. If you 
want to use polling in your device drivers, you should read one of the books dedicated to device driver design, as this is a complex subject.

<BR>

<BR>

<A NAME="E68E414"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Summary</B></FONT></CENTER></H3>

<BR>

<P>Most Linux users will never have to write a device driver, as most devices you can buy already have a device driver available. If you <A NAME="I2"></A>acquire brand new hardware, or have the adventurous bug, you may want to try writing a driver, though. 
Device drivers are not really difficult to write (as long as you are comfortable coding in a high-level language like C), but drivers tend to be very difficult to debug. The device driver programmer must at all times be careful of impacting other processes 
or devices. However, there is a peculiar sense of accomplishment when a device driver executes properly.

<P ALIGN=LEFT>

<A HREF="rhl52.htm" tppabs="http://202.113.16.101/%7eeb%7e/Red%20Hat%20Linux%20Unleashed/rhl52.htm" TARGET="_self"><IMG SRC="purprev.gif" tppabs="http://202.113.16.101/%7eeb%7e/Red%20Hat%20Linux%20Unleashed/purprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>

<A HREF="#I0" TARGET="_self"><IMG SRC="purtop.gif" tppabs="http://202.113.16.101/%7eeb%7e/Red%20Hat%20Linux%20Unleashed/purtop.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Page Top"></A>

<A HREF="index-1.htm" tppabs="http://202.113.16.101/%7eeb%7e/Red%20Hat%20Linux%20Unleashed/index.htm" TARGET="_self"><IMG SRC="purtoc.gif" tppabs="http://202.113.16.101/%7eeb%7e/Red%20Hat%20Linux%20Unleashed/purtoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>

<A HREF="rhl54.htm" tppabs="http://202.113.16.101/%7eeb%7e/Red%20Hat%20Linux%20Unleashed/rhl54.htm" TARGET="_self"><IMG SRC="purnext.gif" tppabs="http://202.113.16.101/%7eeb%7e/Red%20Hat%20Linux%20Unleashed/purnext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>


</BODY></HTML>