It is customary for authors explaining device drivers to start with a complete explanation of character devices, saving block device drivers for a later chapter. To explain why this is, I need to briefly introduce character devices as well. To do that, I’ll give a little history.

When Unix was written 25 years ago, its design was eclectic. One unusual design feature was that every physical device connected to the computer was represented as a file. This was a bold decision, because many devices are very different from one another, especially at first glance. Why use the same interface to talk to a printer as to talk to a disk drive?

The short answer is that while the devices are very much different, they can be thought of as having most of the same characteristics as files. The entire system is then kept smaller and simpler by only using one interface with a few extensions.
A practical effect of the difference is that filesystems can only be mounted on block devices, not on character ones. For example, most tapes are character devices. It is possible to copy the contents of a raw, quiescent (unmounted and not being modified) filesystem to a tape, but you will not be able to mount the tape, even though it contains the same information as the disk.

Most textbooks and tutorials start by explaining character devices, the sequential-access ones, because a minimal character device driver is easier to write than a minimal block device driver. My own Linux Kernel Hackers’ Guide (the KHG) is written the same way.

head    1.3;
access;
symbols;
locks; strict;
comment    @ * @;

1.3
date    2014.01.10.09.25.47;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.09.11.09.19;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.23.58;    author root;    state Exp;
branches;
next    ;

desc
@Header file for init.c and exit .c
@

1.3
log
@header file now only includes header files and macros.
@

——————————————————————————————————————————————————–

head    1.3;
access;
symbols;
locks; strict;
comment    @ * @;

1.3
date    2014.01.10.09.26.29;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.09.11.09.45;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.25.07;    author root;    state Exp;
branches;
next    ;

desc
@all the declerations are done in this file for init.c and exit.c
@

1.3
log
@this file now has the extern declerations
@

——————————————————————————————————————————————————–

head    1.1;
access;
symbols;
locks; strict;
comment    @ * @;

1.1
date    2014.01.10.09.32.30;    author root;    state Exp;
branches;
next    ;

desc
@this file has the mapping of the file_operations fops
open and close.
@

——————————————————————————————————————————————————–

head    1.3;
access;
symbols;
locks; strict;
comment    @ * @;

1.3
date    2014.01.10.09.27.06;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.09.11.05.33;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.29.02;    author root;    state Exp;
branches;
next    ;

desc
@source code fro initialization function
@

1.3
log
@added the definitions of extern declerations
@

——————————————————————————————————————————————————–

head    1.2;
access;
symbols;
locks; strict;
comment    @ * @;

1.2
date    2014.01.10.09.27.33;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.29.47;    author root;    state Exp;
branches;
next    ;

desc
@source code for clean-up function.
@

1.2
log
@added the definitions of extern declerations
@

——————————————————————————————————————————————————–

head    1.1;
access;
symbols;
locks; strict;
comment    @ * @;

1.1
date    2014.01.10.09.33.32;    author root;    state Exp;
branches;
next    ;

desc
@routine for opening the node between kernel and user space
@

——————————————————————————————————————————————————–

head    1.1;
access;
symbols;
locks; strict;
comment    @ * @;

1.1
date    2014.01.10.09.34.09;    author root;    state Exp;
branches;
next    ;

desc
@routine for releasing the node between kernel and user space

——————————————————————————————————————————————————–

head    1.1;
access;
symbols;
locks; strict;
comment    @ * @;

1.1
date    2014.01.10.09.32.26;    author root;    state Exp;
branches;
next    ;

desc
@the application which is calling the driver for file_operations fops.
@

——————————————————————————————————————————————————–

head    1.2;
access;
symbols;
locks; strict;
comment    @# @;

1.2
date    2014.01.10.09.29.33;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.30.54;    author root;    state Exp;
branches;
next    ;

desc
@script file for the code
@

1.2
log
@added the command MKNOD
added the command make app
added the command unlink
@

Loadable kernel module

In computing, a loadable kernel module (or LKM) is an object file that contains code to extend the running kernel, or so-called base kernel, of an operating system. LKMs are typically used to add support for new hardware and/or filesystems, or for adding system calls. When the functionality provided by a LKM is no longer required, it can be unloaded in order to free memory and other resources.

Most current Unix-like systems and Microsoft Windows support loadable kernel modules, although they might use a different name for them, such as kernel loadable module (kld) in FreeBSD, kernel extension (kext) in OS X and kernel-mode driver in Windows NT. They are also known as Kernel Loadable Modules (or KLM), and simply as Kernel Modules (KMOD)

Advantages

Without loadable kernel modules, an operating system would have to include all possible anticipated functionality already compiled directly into the base kernel. Much of that functionality would reside in memory without being used, wasting memory, and would require that users rebuild and reboot the base kernel every time they require new functionality. Most operating systems supporting loadable kernel modules will include modules to support most desired functionality.

Disadvantages

One minor criticism of preferring a modular kernel over a static kernel is the so-called Fragmentation Penalty. The base kernel is always unpacked into real contiguous memory by its setup routines; so, the base kernel code is never fragmented. Once the system is in a state where modules may be inserted—for example, once the filesystems have been mounted that contain the modules—it is probable that any new kernel code insertion will cause the kernel to become fragmented, thereby introducing a minor performance penalty.

Implementation of LKM in linux

Loadable kernel modules in Linux are loaded (and unloaded) by the insmode command. They are located in /lib/modules and have had the extension .ko (“kernel object”) since version 2.6 (previous versions used the .o extension).The lsmod command lists the loaded kernel modules. In emergency cases, when the system fails to boot due to e.g. broken modules, specific modules can be enabled or disabled by modifying the kernel boot parameters list (for example, if using GRUB, by pressing ‘e’ in the GRUB start menu, then editing the kernel parameter line).

In the opinion of Linux maintainers, LKM are derived works of the kernel. The Linux maintainers tolerate the distribution of proprietary modules, but allow symbols to be marked as only available to GNU General Public License (GPL) modules.

Loading a proprietary or non-GPL-compatible LKM will set a ‘taint’ flagin the running kernel—meaning that any problems or bugs experienced will be less likely to be investigated by the maintainers. LKMs effectively become part of the running kernel, so can corrupt kernel data structures and produce bugs.

In 2004, Linuxant—a consulting company that releases proprietary device drivers as loadable kernel modules—attempted to bypass GPLONLY symbol restrictions by abusing a NULL terminator in their

module license i.e.,

MODULE_LICENSE:

MODULE_LICENSE("GPLfor files in the \"GPL\" directory; for others, only LICENSE file applies");

Linux allows disabling module loading via sysctl option /proc/sys/kernel/modules_disabled .An initramfs system may load specific modules needed for a machine at boot and then disable module loading. This makes the security very similar to a monolithic kernel. If an attacker can change the initramfs, they can change the kernel binary.

In programming language, a symbol is either a variable or a function. Or more generally, we can say, a symbol is a name representing an space in the memory, which stores data (variable, for reading and writing) or instructions (function, for executing). To make life easier for cooperation among various kernel function unit, there are thousands of global symbols in Linux kernel.

In general,when we have to use some variable or function outside the scope we use EXTERN or Declare globally similarly in kernal space we use symbol table .Once we EXPORT a module to symbol table it become a part of kerner .On that kernel any user can import that module .The table contains the addresses of global kernel items—functions and variables—that are needed to implement modularized drivers. When a module is loaded, any symbol exported by the module becomes part of the kernel symbol table.you can stack new modules on top of other modules. Module stacking is implemented in the mainstream kernel sources as well.

Character special files or character devices relate to devices through which the system transmits data one character at a time by, for example, getchar. These device nodes often serve for stream communication with devices such as mice, keyboards, virtual terminals, and serial modems, and usually do not support random access to data.

In most implementations, character devices use unbuffered input and output routines. The system reads each character from the device immediately or writes each character to the device immediately.

There are two major ways for a kernel module to talk to processes. One is through device files (like the files in the /dev directory), the other is to use the proc file system. Since one of the major reasons to write something in the kernel is to support some kind of hardware device, we’ll begin with device files.

The original purpose of device files is to allow processes to communicate with device drivers in the kernel, and through them with physical devices (modems, terminals, etc.). The way this is implemented is the following.

Each device driver, which is responsible for some type of hardware, is assigned its own major number. The list of drivers and their major numbers is available in /proc/devices. Each physical device managed by a device driver is assigned a minor number. The /dev directory is supposed to include a special file, called a device file, for each of those devices, whether or not it’s really installed on the system.

head    1.4;
access;
symbols;
locks
root:1.4; strict;
comment @ * @;

1.4
date    2014.01.09.16.52.25;    author root;    state Exp;
branches;
next    1.3;

1.3
date    2014.01.06.17.48.18;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.06.16.35.38;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.15.15.50;    author root;    state Exp;
branches;
next    ;

desc
@Device Driver registration using alloc_chrdev_region
@

1.4
log
@DRIVER INITIALIZATION FOR NO. OF DEVICES AND IMPORT FUNCTION
@

head    1.4;
access;
symbols;
locks
root:1.4; strict;
comment @ * @;

1.4
date    2014.01.09.16.59.43;    author root;    state Exp;
branches;
next    1.3;

1.3
date    2014.01.06.17.48.18;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.06.16.35.38;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.15.15.50;    author root;    state Exp;
branches;
next    ;

desc
@Device Driver registration using alloc_chrdev_region
@

LOG FILE FOR ENTRY OF A MODULE IN KERNEL :

head    1.4;
access;
symbols;
locks
root:1.4; strict;
comment    @ * @;

1.4
date    2014.01.09.16.41.19;    author root;    state Exp;
branches;
next    1.3;

1.3
date    2014.01.06.14.28.40;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.06.14.10.20;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.13.06.31;    author root;    state Exp;
branches;
next    ;

desc
@source file for driver registration using alloc_chrdev_registration .
@

1.4
log
@initialization scull  &  c_dev for multiple devices and export a function in symbol table by using EXPORT_SYMBOL.
@

LOG FILE FOR DELETION OF A MODULE IN KERNEL :

head    1.3;
access;
symbols;
locks
root:1.3; strict;
comment    @ used free & unregister @;

1.3
date    2014.01.06.14.41.04;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.06.14.20.34;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.13.15.52;    author root;    state Exp;
branches;
next    ;

desc
@source file for driver to unregister it from kernel.
@

1.3
log
@ remove the cdev from device table using cdev_del and deallocate the memory too and unregister the driver.
@

head    1.2;
access;
symbols;
locks; strict;
comment    @ * @;

1.2
date    2014.01.09.11.09.19;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.23.58;    author root;    state Exp;
branches;
next    ;

desc
@Header file for init.c and exit .c
@

1.2
log
@nothing is changed as per the project
@

———————————————————————————————————————————————–

head    1.2;
access;
symbols;
locks; strict;
comment    @ * @;

1.2
date    2014.01.09.11.09.45;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.25.07;    author root;    state Exp;
branches;
next    ;

desc
@all the declerations are done in this file for init.c and exit.c
@

1.2
log
@declared the scull function for multiple devices
@

———————————————————————————————————————————————–

head    1.1;
access;
symbols;
locks; strict;
comment    @ * @;

1.1
date    2014.01.06.10.29.47;    author root;    state Exp;
branches;
next    ;

desc
@source code for clean-up function.
@

———————————————————————————————————————————————–

head    1.2;
access;
symbols;
locks; strict;
comment    @ * @;

1.2
date    2014.01.09.11.05.33;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.29.02;    author root;    state Exp;
branches;
next    ;

desc
@source code fro initialization function
@

1.2
log
@created for multiple devices using for loop and exported the function to Symbol Table
@

Implemented the following:

1.Set-up Scull for multiple devices.

2.Export a self made function to symbol table of kernel, and use the function in some other file.

Log file for init.c:

head    1.4;
access;
symbols;
locks
root:1.4; strict;
comment    @ * @;

1.4
date    2014.01.09.11.07.19;    author root;    state Exp;
branches;
next    1.3;

1.3
date    2014.01.06.15.38.44;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.06.14.16.20;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.13.06.31;    author root;    state Exp;
branches;
next    ;

desc
@This is the source file of initialization file of driver initialization by new mechanism.
@

1.4
log
@Setup scull for multiple devices and export a function in symbol table by using EXPORT_SYMBOL.
@

Log file for exit.c:

head    1.3;
access;
symbols;
locks
root:1.3; strict;
comment    @ * @;

1.3
date    2014.01.06.15.41.04;    author root;    state Exp;
branches;
next    1.2;

1.2
date    2014.01.06.14.20.34;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.13.07.52;    author root;    state Exp;
branches;
next    ;

desc
@This is the source file of exit file of driver initialization by new mechanism.
@

1.3
log
@After allocating the memory and adding the cdev to device table, remove the cdev from device table using cdev_del and deallocate the memory too and unregister the driver.
@