SFSU, CSC 415 Device Drivers SFSU, CSC 415 Everything is either a File or a Process ● Since Linux follows the UNIX model, and in UNIX everything is a file, users talk with device drivers through device files. ● Device files are a mechanism, supplied by the kernel, precisely for this direct User-Driver interface. ● Common kinds of device files are a character device file and a block device file. We will only discuss character device files today. 2 SFSU, CSC 415 Tell the kernel what you can do ● The key to device drivers is the registration with the kernel which is comprised of a major version number a name and a list of routines (methods / functions) that your driver can perform. ● The structure file_operations (do not confuse this with the file system which tracks by inode – this is the ”everything is a file” concept of *nix) has all of the prototypes of functions that the kernel and the device driver can utilize together. They include open, release (close), read, write, ioctl, etc. ● You only specify those you support, the rest are set to NULL. 3 SFSU, CSC 415 file_operations 4 SFSU, CSC 415 Preferred method of assignment ● However, there's also a C99 way of assigning to elements of a structure, and this is definitely preferred over using the GNU extension. The version of gcc used when writing this, 2.95, supports the new C99 syntax. You should use this syntax in case someone wants to port your driver. It will help with compatibility: 5 SFSU, CSC 415 Register A Device ● To register a character device we have to call: ● int register_chrdev(unsigned int major, const char *name, struct file_operations *fops); 6 SFSU, CSC 415 IOCTL ● What if you have a device, that you want to read and write to, but you also need to “configure”, how do you setup the configuration for the device? ● Example, a modem on a serial port reads and writes data. But, how do we configure the serial port, baud rate, etc.? ● This is where IOCTL comes in. It is like a back door that the kernel does not control. It allows the “user” to directly interact with the device. ● Each device has its own IOCTL messages and structures. 7 SFSU, CSC 415 Interact with the User ● Through device files ● DEMO 8 SFSU, CSC 415 ● When building a device driver module you first need to make sure that the following includes are the first set in you .c file: ● #include
























































/* Needed by all modules */
#include /* Needed for KERN_ALERT */
#include
9
SFSU, CSC 415
● Then in the same directory as your .c file create a Makefile (called Makefile )
that looks like this:
KERNELDIR=/lib/modules/`uname -r`/build
MODULES = YourModule.ko
obj-m += YourModule.o
all:
make -C $(KERNELDIR) M=$(PWD) modules
clean:
make -C $(KERNELDIR) M=$(PWD) clean
install:
make -C $(KERNELDIR) M=$(PWD) modules_install
quickInstall:
cp $(MODULES) /lib/modules/`uname -r`/extra
10
SFSU, CSC 415
● Change the "YourModule" to the basename of your .c file, then from the
bash shell just run:
make
● What this make file does is call a very complex make file in the current
systems version of /lib/modules (the uname -r generates one of the
components of the path name ). The $PWD is your working directory for
your module so that the make file knows that full path.
● If all goes well it will generate a .ko file (kernel object) that can be loaded
with ...
11
SFSU, CSC 415
● To install your device driver module
○ insmod YourModule.ko #Must be done as root user
● To remove the module (so you can build a new one…)
○ rmmod YourModule.ko
● Mknode (dev file)
12

学霸联盟