1) Compatibility Mode
2) Nibble Mode
3) Byte Mode
4) EPP
5) ECP

Hardware
The pin outs of DB25 connector is shown in the picture below
Parallel Port

The lines in DB25 connector are divided in to three groups, they are

1) Data lines (data bus)
2) Control lines
3) Status lines

As the name refers , data is transferred over data lines , Control lines are used to control the peripheral and of course , the peripheral returns status signals back computer through Status lines. These lines are connected to Data, Control And Status registers internally . The details of parallel port signal lines are given below
Pin No (DB25) Signal name Direction Register – bit Inverted
1 nStrobe Out Control-0 Yes
2 Data0 In/Out Data-0 No
3 Data1 In/Out Data-1 No
4 Data2 In/Out Data-2 No
5 Data3 In/Out Data-3 No
6 Data4 In/Out Data-4 No
7 Data5 In/Out Data-5 No
8 Data6 In/Out Data-6 No
9 Data7 In/Out Data-7 No
10 nAck In Status-6 No
11 Busy In Status-7 Yes
12 Paper-Out In Status-5 No
13 Select In Status-4 No
14 Linefeed Out Control-1 Yes
15 nError In Status-3 No
16 nInitialize Out Control-2 No
17 nSelect-Printer OutControl-3 Yes
18-25 Ground - - -

Parallel port registers
As you know, the Data, Control and status lines are connected to there corresponding registers inside the computer. So by manipulating these registers in program , one can easily read or write to parallel port with programming languages like ‘C’ and BASIC.

The registers found in standard parallel port are ,

1) data register
2) Status register
3) Control register

As there names specifies, Data register is connected to Data lines, Control register is connected to control lines and Status register is connected to Status lines. (Here the word connection does not mean that there is some physical connection between data/control/status lines. The registers are virtually connected to the corresponding lines.). So what ever you write to these registers , will appear in corresponding lines as voltages, Of course, you can measure it with a multimeter. And What ever you give to Parallel port as voltages can be read from these registers(with some restrictions). For example , if we write ’1′ to Data register , the line Data0 will be driven to +5v. Just like this ,we can programmatically turn on and off any of the data lines and Control lines.

Similarly the “modules” entry gives details of all the modules that are currently a part of the kernel.
cat /proc/modules

The proc file system is also very useful when we want to debug a kernel module. While debugging we might want to know the values of various variables in the module or may be the data that module is handling. In such situations we can create a proc entry for our selves and dump what ever data we want to look into in the entry.
We will be using the same example character driver that we created in the previous post to create the proc entry.

The proc entry can also be used to pass data to the kernel by writing into the kernel, so there can be two kinds of proc entries
An entry that only reads data from the kernel space
An entry that reads as well as writes data into and from kernel space.

We will start by creating a proc entry for only reading first and then move to a a proc entry for write.
Creating proc entry:

Kernel provides the following functions to create a proc entry

create_proc_read_entry()
create_proc_entry()

Both of these functions are defined in the file linux/proc_fs.h.

The create_proc_entry is a generic function that allows to create both read as well as write entries.
create_proc_read_entry is a function specific to create only read entries.

Its possible that most of the proc entries are created to read data from the kernel space that is why the kernel developers have provided a direct function to create a read proc entry.

We will first use the create_proc_read_entry to create our entry and then look into create_proc_entry.

The proc entries are basically based on the structure “proc_dir_entry”. Meaning every proc entry that gets created is represented by a structure of the kind
“proc_dir_entry” by the kernel.
The structure “proc_dir_entry” looks as follows in 2.6.33-21

The prototype of the function create_proc_read_entry is

struct proc_dir_entry *create_proc_read_entry(const char *name,
mode_t mode, struct proc_dir_entry *base,
read_proc_t *read_proc, void * data)

name : This the name by which entry will be created under the proc file system.
for eg: if we pass “first_proc_entry” , then it will create a file by the name
first_proc_entry under the /proc directory.
mode : mode sets the permissions for the entry created, if 0 is passed it takes
system default settings
base : Base is the base directory in which the entry should be created, this is
useful when you want to create a proc entry under a sub folder in /proc. If
you pass NULL it will create it under /proc by default
read_proc: read_proc is a pointer to the function that should be called every time
the proc entry is read. The function should be implemented in the
driver. It is this functions which we will use to display what ever data
we want to display to the user.
data : This is not used by the kernel, but is passed as it is to the read_proc
function. The data is used by the driver writer to pass any private data
that has to be passed to the read_proc function. It can be passed as NULL
if no data has to be passed.

Once a module gets registered with the kernel, the corresponding proc entry should also be created. So the call to the function create_read_proc_entry is included in the “init” function of the driver.

Removing a proc entry:

When a module is removed from the kernel, it should also remove any proc entries it created. The function that enables the removal of proc entry is “remove_proc_entry” which has the following prototype
void remove_proc_entry(const char *name, struct proc_dir_entry *parent);

name: Name of the proc entry that has to be removed.
parent: In case the proc entry lies in a subdirectory under the proc filesystem, we
can pass the subdirectories here.

With this introduction to proc filesystem and the corresponding function calls that will allow us to create the entries we can start writing the code to create our first proc entry.

RCS file: default.h,v
Working file: default.h
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
—————————-
revision 1.2
date: 2014/06/28 09:12:31; author: root; state: Exp; lines: +10 -5
used majoe and minor no.
—————————-
revision 1.1
date: 2014/06/27 07:06:18; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: declartion.h,v
Working file: declartion.h
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
—————————-
revision 1.2
date: 2014/06/28 09:13:01; author: root; state: Exp; lines: +20 -0
used sculldev
—————————-
revision 1.1
date: 2014/06/27 07:06:19; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: init.c,v
Working file: init.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
—————————-
revision 1.2 locked by: root;
date: 2014/06/27 10:28:50; author: root; state: Exp; lines: +10 -6
*** empty log message ***
—————————-
revision 1.1
date: 2014/06/27 07:06:07; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
—————————-
revision 1.3
date: 2014/06/28 09:11:41; author: root; state: Exp; lines: +2 -2
exit function for unregister
—————————-
revision 1.2
date: 2014/06/27 10:22:45; author: root; state: Exp; lines: +3 -3
*** empty log message ***
—————————-
revision 1.1
date: 2014/06/27 07:06:14; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: default.h,v
Working file: default.h
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
—————————-
revision 1.2
date: 2014/06/28 09:12:31; author: root; state: Exp; lines: +10 -5
used majoe and minor no.
—————————-
revision 1.1
date: 2014/06/27 07:06:18; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: declartion.h,v
Working file: declartion.h
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
—————————-
revision 1.2
date: 2014/06/28 09:13:01; author: root; state: Exp; lines: +20 -0
used sculldev
—————————-
revision 1.1
date: 2014/06/27 07:06:19; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
used the unregister function
—————————-
revision 1.1 locked by: root;
date: 2014/06/26 05:29:50; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: header.h,v
Working file: header.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
used the headerfile init.h
used the headerfile module.h
also used the headerfile fs.h
—————————-
revision 1.1 locked by: root;
date: 2014/06/26 05:29:50; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: default.h,v
Working file: default.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
in this difine the majorno
also define the device name
—————————-
revision 1.1 locked by: root;
date: 2014/06/26 05:29:50; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: declartion.h,v
Working file: declartion.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
used the extern
—————————-
revision 1.1 locked by: root;
date: 2014/06/26 05:29:50; author: root; state: Exp;
Initial revision
=============================================================================

If you choose to write a device driver, you must take everything written here as a guide, and no more. I cannot guarantee that this chapter will be free of errors, and I cannot guarantee that you will not damage your computer, even if you follow these instructions exactly. It is highly unlikely that you will damage it, but I cannot guarantee against it. There is only one “infallible” direction I can give you: Back up! Back up before you test your new device driver, or you may regret it later.

What is a Device Driver?
What is this “device driver” stuff anyway? Here’s a very short introduction to the concept.
User-space device drivers
It’s not always necessary to write a “real” device driver. Sometimes you just need to know how to write code that runs as a normal user process and still accesses hardware.
Device Driver Basics
Assuming that you need to write a “real” device driver, there are some things that you need to know regardless of what type of driver you are writing. In fact, you may need to learn what type of driver you ought to write…
Character Device Drivers
This section includes details specific to character device drivers, and assumes that you know everything in the previous section.
TTY drivers
This section hasn’t been written yet. TTY drivers are character devices that interface with the kernel’s generic TTY support, and they require more than just a standard character device interface. I’d appreciate it if someone would write up how to attach a character device driver to the generic TTY layer and submit it to me for inclusion in this guide.
Block Device Drivers
This section includes details specific to block device drivers (suprise!)
Writing a SCSI Device Driver
This is a technical paper written by Rik Faith at the University of North Carolina.
Network Device Drivers
Alan Cox gives an introduction to the network layer, including device drivers.
Supporting Functions
Many functions are useful to all sorts of drivers. Here is a summary of quite a few of them.
Translating Addresses in Kernel Space
An edited version of a post of Linus Torvalds to the linux-kernel mailing list about how to correctly deal with translating memory references when writing kernel source code such as device drivers.
Kernel-Level Exception Handling
An edited version of a post of Joerg Pommnitz to the linux-kernel mailing list about how the new exception mechanism works.

intoduction of divice driver:-

One of the many advantages of free operating systems, as typified by Linux, is that their internals are open for all to view. The operating system, once a dark and mysterious area whose code was restricted to a small number of programmers, can now be readily examined, understood, and modified by anybody with the requisite skills. Linux has helped to democratize operating systems. The Linux kernel remains a large and complex body of code, however, and would-be kernel hackers need an entry point where they can approach the code without being overwhelmed by complexity. Often, device drivers provide that gateway.

Device drivers take on a special role in the Linux kernel. They are distinct “black boxes” that make a particular piece of hardware respond to a well-defined internal programming interface; they hide completely the details of how the device works. User activities are performed by means of a set of standardized calls that are independent of the specific driver; mapping those calls to device-specific operations that act on real hardware is then the role of the device driver. This programming interface is such that drivers can be built separately from the rest of the kernel and “plugged in” at runtime when needed. This modularity makes Linux drivers easy to write, to the point that there are now hundreds of them available.

There are a number of reasons to be interested in the writing of Linux device drivers. The rate at which new hardware becomes available (and obsolete!) alone guarantees that driver writers will be busy for the foreseeable future. Individuals may need to know about drivers in order to gain access to a particular device that is of interest to them. Hardware vendors, by making a Linux driver available for their products, can add the large and growing Linux user base to their potential markets. And the open source nature of the Linux system means that if the driver writer wishes, the source to a driver can be quickly disseminated to millions of users.

This book teaches you how to write your own drivers and how to hack around in related parts of the kernel. We have taken a device-independent approach; the programming techniques and interfaces are presented, whenever possible, without being tied to any specific device. Each driver is different; as a driver writer, you need to understand your specific device well. But most of the principles and basic techniques are the same for all drivers. This book cannot teach you about your device, but it gives you a handle on the background you need to make your device work.

As you learn to write drivers, you find out a lot about the Linux kernel in general; this may help you understand how your machine works and why things aren’t always as fast as you expect or don’t do quite what you want. We introduce new ideas gradually, starting off with very simple drivers and building on them; every new concept is accompanied by sample code that doesn’t need special hardware to be tested.

This chapter doesn’t actually get into writing code. However, we introduce some background concepts about the Linux kernel that you’ll be glad you know later, when we do launch into programming.