what is a device driver?

a program that brokers between a user program and a piece of hardware.

provices a basis where you as the end user need to know as little as possible about the hardware.
example of hardware abstraction in a microcomputer: xserver knows about hardware but window manager doesn't.

most of kernel hacking is writing device drivers.

kernel modularization:

kernel modularization is a relatively new concept.

kernels used to be one self contained piece of code.

more modern kernels: there is a mechanism whereby at runtime object files can be attached to and interact with the kernel at runtime.

such an object file is referred to as a kernel module.

these modules make it convenient to write and test device drivers.

sort of like adding to a running program (e.g. if you insmod slip and then send data over serial port you can at the same time insmod something else).

example of creation, installation, and use of a device driver:

gcc devicedriver.c -O2 (must have opt. on, to expand any inline macros)
insmod devicedriver.o (extend the kernel at runtime by adding kernel modules...)
cat myfile > /dev/devicedriver (in unix attempt is made to make all hardware appear as a linear sequence of bytes).

the kernel identifies what code to run not by the filename of the dev driver but by the major and minor numbers.
there is a central registry of major numbers.
there's a way to request major numbers and we'll be doing that in the lab.
then make an inode typically in the dev directory: mknod ...

everything in the dev dir looks like a file;

there are commonly 2 kinds of devices, block devices and character devices (a third kind, network devices, won't be talked about now)

block devices: e.g. get a block (e.g. 512 bytes) at a time.

brw-r-----   1 root     disk       3,   0 Jul 20  1998 hda
brw-r-----   1 root     disk       3,   1 Jul 20  1998 hda1
brw-r-----   1 root     disk       3,   2 Jul 20  1998 hda2
brw-r-----   1 root     disk       3,   3 Jul 20  1998 hda3

character devices, e.g. serial (hardware accessed 1 char at a time, e.g. serial port, parallel port, sound /dev/dsp)

crw-------   1 root     tty        4,  64 Jul 20  1998 ttyS0
crw-------   1 root     tty        4,  65 Jul 20  1998 ttyS1
crw-r--r--   1 root     tty        4,  66 Jul 20  1998 ttyS2
crw-r--r--   1 root     tty        4,  67 Jul 20  1998 ttyS3

crw-rw--w-   1 root     sys       14,   3 Jul 20  1998 /dev/dsp
example of usage where device driver is treated like file:
cat ____ > dev/dsp
cat /dev/dsp > 

design philosophy: make devices look like files.

13 things we can do to files:

not all used foreach device, e.g. readdir only needed if directories present...

device drivers often call other device drivers, for example,

axattach slattach are device driver helper daemons.
other examples: file systems that live on top of hardware.

example of device driver that calls another device driver

newer kernels (2.2) paraport manages the parallel port hardware (plip talked to hardware directly in 2.0 or less)
insmod paraport
insmod plip
plip is a dev driver that depends on paraport

kernel is like a big library.
libraries don't run by themselves.
kernel is not live in any sense.
it doesn't have a context of execution. userspace programs call kernel

device drivers don't run.
kernel doesn't run.
they're like subroutines or libraries that your program calls.
calling a library is a JSR to the code. system call is like a BRK instruction.

LDA interrupt code.
BRK (00)
on the x86: load EAX register, then call the TRAP opcode;
cpu goes into supervisory mode (interrupts cause cpu to go into supervisory mode).
a trap is an instruction that generates an interrupt. (interrupt = exception).
signal a process can get. restartable: e.g. math exception signal. e.g. division by zero error. restartable: another example: bus error

interrupts need to be prioritized:
example: printer signals needs more data then page fault occurs.

the term interrupt has fallen out of favor because you're not really stopping a process, in fact interrupts are generated to keep the process going. e.g. plip keeps interrupting as part of the normal process. interrupt is a signal to start rather than stop.

societal analogy of kernel:

processes get together to form a gov't and the kernel is the gov't. all the processes agree to run under it, whereas MACos is like an anarchy. in DOS everything runs in supervisor mode supervisor bit in the status register is set.

device drivers: keep the code short and simple.
kernel tasks are not preemptable debugging kernel code is harder, e.g. can't use gdb.
also if you make a bug can have drastic effect on computer (e.g. clobber hard drive).
if you enter inf. loop in kernelspace there's no way to stop it without rebooting computer (unless kernel profiling support).

device drivers: fundamental device driver concepts