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.
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).
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;
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/dspexample of usage where device driver is treated like file:
cat ____ > dev/dsp cat /dev/dsp >
design philosophy: make devices look like 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.
insmod paraport insmod plipplip 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;
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.
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