As a programmer, you will be able to make your own choices about your driver, choosing an acceptable trade-off between the programming time required and the flexibility of the result. Though it may appear strange to say that a driver is “flexible,” we like this word because it emphasizes that the role of a device driver is providing mechanism, not policy.

The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: “what capabilities are to be provided” (the mechanism) and “how those capabilities can be used” (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs.

For example, Unix management of the graphic display is split between the X server, which knows the hardware and offers a unified interface to user programs, and the window and session managers, which implement a particular policy without knowing anything about the hardware. People can use the same window manager on different hardware, and different users can run different configurations on the same workstation. Even completely different desktop environments, such as KDE and GNOME, can coexist on the same system. Another example is the layered structure of TCP/IP networking: the operating system offers the socket abstraction, which implements no policy regarding the data to be transferred, while different servers are in charge of the services (and their associated policies). Moreover, a server like ftpd provides the file transfer mechanism, while users can use whatever client they prefer; both command-line and graphic clients exist, and anyone can write a new user interface to transfer files.

Where drivers are concerned, the same separation of mechanism and policy applies. The floppy driver is policy free — its role is only to show the diskette as a continuous array of data blocks. Higher levels of the system provide policies, such as who may access the floppy drive, whether the drive is accessed directly or via a filesystem, and whether users may mount filesystems on the drive. Since different environments usually need to use hardware in different ways, it’s important to be as policy free as possible.

When writing drivers, a programmer should pay particular attention to this fundamental concept: write kernel code to access the hardware, but don’t force particular policies on the user, since different users have different needs. The driver should deal with making the hardware available, leaving all the issues about how to use the hardware to the applications. A driver, then, is flexible if it offers access to the hardware capabilities without adding constraints. Sometimes, however, some policy decisions must be made. For example, a digital I/O driver may only offer byte-wide access to the hardware in order to avoid the extra code needed to handle individual bits.

You can also look at your driver from a different perspective: it is a software layer that lies between the applications and the actual device. This privileged role of the driver allows the driver programmer to choose exactly how the device should appear: different drivers can offer different capabilities, even for the same device. The actual driver design should be a balance between many different considerations. For instance, a single device may be used concurrently by different programs, and the driver programmer has complete freedom to determine how to handle concurrency. You could implement memory mapping on the device independently of its hardware capabilities, or you could provide a user library to help application programmers implement new policies on top of the available primitives, and so forth. One major consideration is the trade-off between the desire to present the user with as many options as possible and the time in which you have to do the writing as well as the need to keep things simple so that errors don’t creep in.

Policy-free drivers have a number of typical characteristics. These include support for both synchronous and asynchronous operation, the ability to be opened multiple times, the ability to exploit the full capabilities of the hardware, and the lack of software layers to “simplify things” or provide policy-related operations. Drivers of this sort not only work better for their end users, but also turn out to be easier to write and maintain as well. Being policy free is actually a common target for software designers.

Many device drivers, indeed, are released together with user programs to help with configuration and access to the target device. Those programs can range from simple utilities to complete graphical applications. Examples include the tunelpprogram, which adjusts how the parallel port printer driver operates, and the graphical cardctl utility that is part of the PCMCIA driver package. Often a client library is provided as well, which provides capabilities that do not need to be implemented as part of the driver itself.

The scope of this book is the kernel, so we’ll try not to deal with policy issues, or with application programs or support libraries. Sometimes we’ll talk about different policies and how to support them, but we won’t go into much detail about programs using the device or the policies they enforce. You should understand, however, that user programs are an integral part of a software package and that even policy-free packages are distributed with configuration files that apply a default behavior to the underlying mechanisms.

Client-Server Model

A standard model for distributed applications is the client-server model. A server is a process that is waiting to be contacted by a client process so that the server can do something or the client. A typical scenario is as follows:

• The server process is started on some computer system. It initializes itself, then goes to sleep waiting for a client process to contact it requesting some service.
• A client process is started, either on the same system or on another system that is connected to the server’s system with a network. The client process sends a request across the network to the server requesting a service of some form.
• When the server process has finished providing its service to the client, the server goes back to sleep, waiting for the next client request to arrive.

Socket definition

A communication between two processes running on two computer systems can be completely specified by the association: {protocol, local-address, local-process, remote-address, remote-process} We also define a half association as either {protocol, local-address, local-process} or {protocol, remote-address, remote-process}, which specify half of a connection. This half association is also called socket, or transport address. The term socket has been popularized by the Berkeley Unix networking system, where it is “an end point of communication”, which corresponds to the definition of half association.

System calls related to sockets

For a UNIX file, there are six system calls for input/output (I/O): open, create, close, read, write and lseek. All these system calls work with a file descriptor, a number corresponding to a certain file. It would be nice if the interface to the network facilities maintained the file descriptor semantics of the Unix file system, but network I/O involves more details and options than the file input/output. However, the difference is not extremely big.

This figure shows a time line of a typical scenario that takes place for a connection-oriented transfer. First the server is started, then sometimes later a client is started that connects to the server.

To do network I/O, the first thing a process must do is call the socket (see the man page for the system calls presented, e.g. man -s3n socket) system call, specifying the type of communication protocol desired.

#include <sys/types.h>
#include <sys/socket.h>

int socket(int family, int type, int protocol);

for our lab, we will use only the internet protocols and stream socket type, so the function call will look like: sockfd = socket(AF_INET, SOCK_STREAM, 0); The socket system call returns a small integer value, similar to a file descriptor. We call this a socket descriptor, or a sockfd.

Up to now, for the association {protocol, local-address, local-process, remote-address, remote-process} we have only specified the protocol. In order to fill the local-address and local-process elements of the association we will use the bind system call.

#include <sys/types.h>
#include <sys/socket.h>

int bind(int sockfd, struct sockaddr *myaddr, int addrlen);

The second argument of bind is a pointer to a protocol-specific address, and the third argument is the size of the address structure. bind tells the system “this is my address and any messages received for this address are to be given to me”.

Then, the server indicates that is willing to receive connections:

 
int listen(int sockfd, int backlog); 

The backlog argument specifies how many connection requests can be queued by the system while it waits for the server to execute the accept system call.

After executing the listen system call, an actual connection is waited for by having the server execute the accept system call.

#include <sys/types.h>
#include <sys/socket.h>

int accept(int sockfd, struct sockaddr *peer, int *addrlen);

accept takes the first connection request from the queue, and creates another socket with the same proprieties as sockfd. When a connection request is received and accepted, the new socket descriptor returned by accept refers to a complete association {protocol, remote-address, remote-process} with the last two fields filled with information from the client. The client’s address is also set in the second (*peer) parameter together with its length, *addrlen;

A client process connects to a socket descriptor following the socket system call to establish a connection with a server:

#include <sys/types.h>
#include <sys/socket.h>

int connect(int sockfd, struct sockaddr *servaddr, int addrlen);

The sockfd is a socket descriptor that was returned by the socket system call. The second and the third argument are a pointer to a socket address, and its size.

From now on, the server and the client can use the write/read system calls for file descriptors in order to communicate. Stream sockets exhibit a behaviour with the read and write system calls that differs from normal file I/O. A read or a write on a socket might input or output fewer bytes than requested, but this is not an error condition. The reason is that buffer limits might be reached for the socket in the kernel and all that is required is for the caller to invoke the read or write system call again, for the remaining bytes.

Many of the socket system calls require a pointer to a socket address structure as an argument. The definition of this structure is in

<sys/socket.h>:

struct sockaddr {
	u_short 	sa_family; /* address_family: AF_xxx value */	
	char 		sa_data[14];
};

The contents of the 14 bytes of protocol-specific address are interpreted according to the type of address. For the Internet family, the following structures are defined in <netinet/in.h>:

struct in_addr {
	u_long 		s_addr; /* 32 bit netid/hostid */
};

struct sockaddr_in {
	short 		sin_family; 		/* AF_INET */
	u_short 	sin_port; 		/* 16 bit port number, network byte ordered */
	srtuct in_addr 	sin_addr; 		/* 32 bit netid/hostid, network byte ordered */
	char 		sin_zero[8]; 		/* unused */
}

Both the client and the server close their sockets using the close function call.

A thread of execution is often regarded as the smallest unit of processing that a scheduler works on.

A process can have multiple threads of execution which are executed asynchronously.

This asynchronous execution brings in the capability of each thread handling a particular work or service independently. Hence multiple threads running in a process handle their services which overall constitutes the complete capability of the process.

In this article we will touch base on the fundamentals of threads and build the basic understanding required to learn the practical aspects of Linux threads.

Why Threads are Required?

Now, one would ask why do we need multiple threads in a process?? Why can’t a process with only one (default) main thread be used in every situation.

Well, to answer this lets consider an example :

Suppose there is a process, that receiving real time inputs and corresponding to each input it has to produce a certain output. Now, if the process is not multi-threaded ie if the process does not involve multiple threads, then the whole processing in the process becomes synchronous. This means that the process takes an input processes it and produces an output.

The limitation in the above design is that the process cannot accept an input until its done processing the earlier one and in case processing an input takes longer than expected then accepting further inputs goes on hold.

To consider the impact of the above limitation, if we map the generic example above with a  socket server process that can accept input connection, process them and provide the socket client with output. Now, if in processing any input if the server process takes more than expected time and in the meantime another input (connection request) comes to the socket server then the server process would not be able to accept the new input connection as its already stuck in processing the old input connection. This may lead to a connection time out at the socket client which is not at all desired.

This shows that synchronous model of execution cannot be applied everywhere and hence was the requirement of asynchronous model of execution felt which is implemented by using threads.

Difference Between threads and processes

Following are some of the major differences between the thread and the processes :

• Processes do not share their address space while threads executing under same process share the address space.
• From the above point its clear that processes execute independent of each other and the synchronization between processes is taken care by kernel only while on the other hand the thread synchronization has to be taken care by the process under which the threads are executing
• Context switching between threads is fast as compared to context switching between processes
• The interaction between two processes is achieved only through the standard inter process communication while threads executing under the same process can communicate easily as they share most of the resources like memory, text segment etc

User threads Vs Kernel Threads

Threads can exist in user space as well as in kernel space.

A user space threads are created, controlled and destroyed using user space thread libraries. These threads are not known to kernel and hence kernel is nowhere involved in their processing. These threads follow co-operative multitasking where-in a thread releases CPU on its own wish ie the scheduler cannot preempt the thread. Th advantages of user space threads is that the switching between two threads does not involve much overhead and is generally very fast while on the negative side since these threads follow co-operative multitasking so if one thread gets block the whole process gets blocked.

A kernel space thread is created, controlled and destroyed by the kernel. For every thread that exists in user space there is a corresponding kernel thread. Since these threads are managed by kernel so they follow preemptive multitasking where-in the scheduler can preempt a thread in execution with a higher priority thread which is ready for execution. The major advantage of kernel threads is that even if one of the thread gets blocked the whole process is not blocked as kernel threads follow preemptive scheduling while on the negative side the context switch is not very fast as compared to user space threads.

If we talk of Linux then kernel threads are optimized to such an extent that they are considered better than user space threads and mostly used in all scenarios except where prime requirement is that of cooperative multitasking.

Problem with Threads

There are some major problems that arise while using threads :

• Many operating system does not implement threads as processes rather they see threads as part of parent process. In this case, what would happen if a thread calls fork() or even worse what if a thread execs a new binary?? These scenarios may have dangerous consequences for example in the later problem the whole parent process could get replaced with the address space of the newly exec’d binary. This is not at all desired.  Linux which is POSIX complaint makes sure that calling a fork() duplicates only the thread that has called the fork() function while an exec from any of the thread would stop all the threads in the parent process.
• Another problem that may arise is the concurrency problems. Since threads share all the segments (except the stack segment) and can be preempted at any stage by the scheduler than any global variable or data structure that can be left in inconsistent state by preemption of one thread could cause severe problems when the next high priority thread executes the same function and uses the same variables or data structures.

For the problem 1 mentioned above, all we can say is that its a design issue and design for applications should be done in a way that least problems of this kind arise.

For the problem 2 mentioned above, using locking mechanisms programmer can lock a chunk of code inside a function so that even if a context switch happens (when the function global variable and data structures were in inconsistent state) then also next thread is not able to execute the same code until the locked code block inside the function is unlocked by the previous thread (or the thread that acquired it

The CPU is not the only intelligent device in the system, every physical device has its own hardware controller. The keyboard, mouse and serial ports are controlled by a SuperIO chip, the IDE disks by an IDE controller, SCSI disks by a SCSI controller and so on. Each hardware controller has its own control and status registers (CSRs) and these differ between devices. The CSRs for an Adaptec 2940 SCSI controller are completely different from those of an NCR 810 SCSI controller. The CSRs are used to start and stop the device, to initialize it and to diagnose any problems with it. Instead of putting code to manage the hardware controllers into every application, the code is kept in the Linux kernel. The software that handles or manages a hardware controller is known as a device driver. The Linux kernel device drivers are, essentially, a shared library of privileged, memory resident, low level hardware handling routines. It is Linux’s device drivers that handle the peculiarities of the devices they are managing.

Linux supports three types of hardware devices: character, block and network. Character devices are read and written directly without buffering, for example the system’s serial ports /dev/cua0 and /dev/cua1. Block devices can only be written to and read from in multiples of the block size, typically 512 or 1024 bytes. Block devices are accessed via the buffer cache and may be randomly accessed, that is to say, any block can be read or written no matter where it is on the device. Block devices can be accessed via their device special file but more commonly they are accessed via the file system. Only a block device can support a mounted file system. Network devices are accessed via the BSD socket interface and the networking subsytems described in the section on networking.

There are many different device drivers in the Linux kernel (that is one of Linux’s strengths) but they all share some common attributes:

Kernel code

Device drivers are part of the kernel and, like other code within the kernel, if they go wrong they can seriously damage the system. A badly written driver may even crash the system, possibly corrupting file systems and losing data. 

Kernel interfaces

Device drivers provide a standard interface to the Linux kernel or to the appropriate subsystem. For example, the terminal driver provides a file I/O interface to the Linux kernel and a SCSI device driver provides a SCSI device interface to the SCSI subsystem which, in turn, provides both file I/O and buffer cache interfaces to the kernel. 

Kernel mechanisms and services

Device drivers make use of standard kernel services such as memory allocation, interrupt delivery and wait queues to operate. 

Loadable

Most of the Linux device drivers can be loaded on demand as kernel modules when they are needed and unloaded when they are no longer being used. This makes the kernel very adaptable and efficient with the system’s resources. 

Configurable

Linux device drivers can be built into the kernel. Which devices are built is configurable when the kernel is compiled. 

Dynamic

As the system boots and each device driver is initialized it looks for the hardware devices that it will control. If those devices do not exist (maybe are just not found), the device driver is simply redundant and causes no harm apart from occupying a little of the system’s memory.

Memory

Device drivers have to be careful when using memory. As they are part of the Linux kernel they cannot use virtual memory. Each time a device driver runs, maybe as an interrupt is received or as a bottom half or task queue handler is scheduled, the current process may change. The device driver cannot rely on a particular process running even if it is doing work on its behalf. Like the rest of the kernel, device drivers use data structures to keep track of the device they controll. The kernel would become unnecessarily large if these data structures were statically allocated, part of the device driver’s code. Most device drivers allocate kernel, non-paged, memory to hold their data.

Linux provides kernel memory allocation and deallocation routines and it is these that the device drivers use. Kernel memory is allocated in chunks that are powers of 2. For example 128 or 512 bytes, even if the device driver asks for less. The number of bytes that the device driver requests is rounded up to the next block size boundary. This makes kernel memory deallocation easier as the smaller free blocks can be recombined into bigger blocks.

It may be that Linux needs to do quite a lot of extra work when the kernel memory is requested. If the amount of free memory is low, physical pages may need to be discarded or written to the swap device. Normally, Linux would suspend the requestor, putting the process onto a wait queue until there is enough physical memory. Not all device drivers (or indeed Linux kernel code) may want this to happen and so the kernel memory allocation routines can be requested to fail if they cannot immediately allocate memory.

The device driver can also specify that it wants to DMA to and from the memory it allocates. It is the Linux kernel, not the device driver, however, that takes care of the details. This way it is the Linux kernel rather than the device driver decides what constitutes DMA’able memory for the system.

Interfacing Device Drivers with the Kernel

To ensure that access is always done in the correct manner, the Linux kernel must be able to interact with device drivers in standard ways. Each class of device driver, character, block and network, provides common interfaces that the kernel uses when requesting services from them. These common interfaces mean that the kernel can treat often very different devices and their device drivers absolutely the same. For example, SCSI and IDE disks behave very differently but the Linux kernel uses the same interface to both of them.

Linux is very dynamic, every time a Linux kernel boots it may encounter different physical devices and thus need different device drivers. Linux allows you to include device drivers at kernel build time via its configuration scripts. When these drivers are initialized at boot time they may not discover any hardware to control. Other drivers can be loaded as kernel modules when they are needed. To cope with this dynamic nature of device drivers, device drivers register themselves with the kernel as they are initialized. Linux maintains tables of registered device drivers as part of its interfaces with them. These tables include pointers to routines and information that supports the interface with the device class.

Character Devices

Figure: Character Devices

Character devices, the simplest of Linux’s devices, are accessed as files, applications use standard system calls to open them, read from them, write to them and close them exactly as if the device were a file. This is true even if the device is a modem being used by the PPP daemon to connect a Linux system onto a network. As a character device is initialized its device driver registers itself with the Linux kernel by adding an entry into the chrdevs vector of device_struct data structures. The device’s major device identifier (for example 4 for the tty device) is used as an index into this vector. The major device identifier for a device is fixed.

Each entry in the chrdevs vector, a device_struct data structure contains two elements: a pointer to the name of the registered device driver and a pointer to a block of file operations. This block of file operations is itself the addresses of routines within the character device driver, each of which handles specific file operations such as open, read, write and close. The contents of /proc/devices for character devices is taken from the chrdevs vector.

When a character special file representing a character device (for example /dev/cua0) is opened, the kernel must set things up so that the correct character device driver’s file operation routines will be called. Just like an ordinairy file or directory, each device special file is represented by a VFS inode . The VFS inode for a character special file, indeed for all device special files, contains both the major and minor identifiers for the device. This VFS inode was created by the underlying filesystem, for example EXT2, from information in the real filesystem when the device special file’s name was looked up.

Each VFS inode has associated with it a set of file operations and these are different depending on the filesystem object that the inode represents. Whenever a VFS inode representing a character special file is created, its file operations are set to the default character device operations.

This has only one file operation, the open file operation. When the character special file is opened by an application the generic open file operation uses the device’s major identifier as an index into the chrdevs vector to retrieve the file operations block for this particular device. It also sets up the file data structure describing this character special file, making its file operations pointer point to those of the device driver. Thereafter all of the applications file operations will be mapped to calls to the character devices set of file operations.

Block Devices

First let me give you a brief idea of architecture which helped me to create my device driver. Its is mainly divided in two basic parts first one is know as your USER LEVEL where application runs and the 2nd is your KERNEL LEVEL where your device driver is defined.

This is how a link is created between application and device through device driver.

APPLICATION——->NODE——>DEVICE DRIVER——–> DEVICE

NODE is an interface between USER LEVEL and KERNEL LEVEL..

There are few kernel defined structure and rest are user defined structure through which we can define the functionality of our device driver.

KERNEL DEFINED STRUCTURE– 1->Struct File 2->struct Inode 3->Cdev. etc

USER DEFINED STRUCTURE– 1->struct ScullDev 2-> struct Scullqset 3->struct file operations.

Lets look how all these all structure works one by one.

Scull is a memory space which is allocated in machine memory to your device. in scull we have two vital structure know as struct Sculldev and struct Scullqset. The former one is the starting point of scull as well as contains data about all the scullqset present in your scull in a way it contains metadata. its member are as fallow- 1-*scullqset 2-no of scullqset 3-datasize 4-quantum size 5-device size. and last but not the least  struct Cdev.

The later one Scullqset is a structure which store data or information. it mainly has two member first one is a pointer to next scullqset and the second one double pointer to y.our data, means first it will point to an array of pointer known as qset ,contains the add of quantum where actually our data is kept.

Struct file operations-> it generally defines the behavior of our device. it is used here to map the user level system calls to programmer defined system calls. some system calls are OPEN,CLOSE,WRITE,READ… etc

Struct Cdev—> it mainly has three member 1st one is owner which specifies about its owner name 2nd is a pointer to file operation,3rd to dev which contains major and minor no. now what is this major and minor no. lets have a look before we proceed further

Major no is a number which is given to each and every device driver we have in our machine and minor no is the number which represents your the device associated with that particular device driver. struct Cdev is your device representation in kernel Space.

Now comes kernel level structures into picture. STRUCT INODE .. as we all know that in linux everything is file either it is a text file, some kind of code or any device with each and every file there is an associated inode structure , here we will mainly concentrate and concerned about which is particularly represents our device. “inode is the only way through which we can or its better to say our application can interact with our device. main member are i_cev which points to your struct cdev. pointer to file operations.

Struct file-> members are *f_pos which takes the account of the cursor in your file. pointer to file operations , *private data which will help us to do mapping from your user level to kernal level as its stores the address of your SCULL so we can access all the data which we have stored in quantum part of scullqset from user level. this is all about the architecture now lets have  look on the operations or working.

STEPS TO BE FOLLOWED:

1. Insmod which will load our module, module is a source code which is loaded on demand.

2. Registration:register our device driver and device so that DD will get a major number and device gets its own minor number.

3.Allocation: Allocate space to Scull in machine memory.

4.Initialize Scull–> cdev_init— create link between struct inode and struct cdev… define owner.. cdev_add make attribute of device available to our kernael.

5. Sculldev initiallization: define size of qset,quantun,device..etc

6. Scull Trim. flash data if present in the memory space which is assigned to scull

7.Open: define open system call.

8. Write: before doing that allocate space to Scullqset then to qset and at last to quantum now we can write data to our quantum, LSEEK if needed.

9. Read: read whatever you have written to quantum.

10. Release: de-allocate all the space, unregister your device and DD, remove your module

Character Device Driver: In order to create a link between your device means your hardware either it is internal or externally attached and user application we need a set of rules which will define how your concerned device shall deal with application make sure user will get a satisfactory output as desired.

First let me give you a brief idea of architecture which helped me to create my device driver. Its is mainly divided in two basic parts first one is know as your USER LEVEL where application runs and the 2nd is your KERNEL LEVEL where your device driver is defined.

This is how a link is created between application and device through device driver.

APPLICATION——->NODE——>DEVICE DRIVER——–> DEVICE

NODE is an interface between USER LEVEL and KERNEL LEVEL..

There are few kernel defined structure and rest are user defined structure through which we can define the functionality of our device driver.

KERNEL DEFINED STRUCTURE– 1->Struct File 2->struct Inode 3->Cdev. etc

USER DEFINED STRUCTURE– 1->struct ScullDev 2-> struct Scullqset 3->struct file operations.

Lets look how all these all structure works one by one.

Scull is a memory space which is allocated in machine memory to your device. in scull we have two vital structure know as struct Sculldev and struct Scullqset. The former one is the starting point of scull as well as contains data about all the scullqset present in your scull in a way it contains metadata. its member are as fallow- 1-*scullqset 2-no of scullqset 3-datasize 4-quantum size 5-device size. and last but not the least  struct Cdev.

The later one Scullqset is a structure which store data or information. it mainly has two member first one is a pointer to next scullqset and the second one double pointer to y.our data, means first it will point to an array of pointer known as qset ,contains the add of quantum where actually our data is kept.

Struct file operations-> it generally defines the behavior of our device. it is used here to map the user level system calls to programmer defined system calls. some system calls are OPEN,CLOSE,WRITE,READ… etc

Struct Cdev—> it mainly has three member 1st one is owner which specifies about its owner name 2nd is a pointer to file operation,3rd to dev which contains major and minor no. now what is this major and minor no. lets have a look before we proceed further

Major no is a number which is given to each and every device driver we have in our machine and minor no is the number which represents your the device associated with that particular device driver. struct Cdev is your device representation in kernel Space.

Now comes kernel level structures into picture. STRUCT INODE .. as we all know that in linux everything is file either it is a text file, some kind of code or any device with each and every file there is an associated inode structure , here we will mainly concentrate and concerned about which is particularly represents our device. “inode is the only way through which we can or its better to say our application can interact with our device. main member are i_cev which points to your struct cdev. pointer to file operations.

Struct file-> members are *f_pos which takes the account of the cursor in your file. pointer to file operations , *private data which will help us to do mapping from your user level to kernal level as its stores the address of your SCULL so we can access all the data which we have stored in quantum part of scullqset from user level. this is all about the architecture now lets have  look on the operations or working.

STEPS TO BE FOLLOWED:

1. Insmod which will load our module, module is a source code which is loaded on demand.

2. Registration:register our device driver and device so that DD will get a major number and device gets its own minor number.

3.Allocation: Allocate space to Scull in machine memory.

4.Initialize Scull–> cdev_init— create link between struct inode and struct cdev… define owner.. cdev_add make attribute of device available to our kernael.

5. Sculldev initiallization: define size of qset,quantun,device..etc

6. Scull Trim. flash data if present in the memory space which is assigned to scull

7.Open: define open system call.

8. Write: before doing that allocate space to Scullqset then to qset and at last to quantum now we can write data to our quantum, LSEEK if needed.

9. Read: read whatever you have written to quantum.

10. Release: de-allocate all the space, unregister your device and DD, remove your module

Char devices are accessed through names in the filesystem. Those names are called special files or device files or simply nodes of the filesystem tree; they are conventionally located in the /dev directory. Special files for char drivers are identified by a “c” in the first column of the output of ls -l. Block devices appear in /dev as well, but they are identified by a “b.” The focus of this chapter is on char devices, but much of the following information applies to block devices as well.

If you issue the ls -l command, you’ll see two numbers (separated by a comma) in the device file entries before the date of last modification, where the file length normally appears. These numbers are the major device number and minor device number for the particular device. The following listing shows a few devices as they appear on a typical system. Their major numbers are 1, 4, 7, and 10, while the minors are 1, 3, 5, 64, 65, and 129.

 crw-rw-rw- 1 root   root    1, 3   Feb 23 1999  null
 crw------- 1 root   root   10, 1   Feb 23 1999  psaux
 crw------- 1 rubini tty     4, 1   Aug 16 22:22 tty1
 crw-rw-rw- 1 root   dialout 4, 64  Jun 30 11:19 ttyS0
 crw-rw-rw- 1 root   dialout 4, 65  Aug 16 00:00 ttyS1
 crw------- 1 root   sys     7, 1   Feb 23 1999  vcs1
 crw------- 1 root   sys     7, 129 Feb 23 1999  vcsa1
 crw-rw-rw- 1 root   root    1, 5   Feb 23 1999  zero

The major number identifies the driver associated with the device. For example, /dev/null and /dev/zero are both managed by driver 1, whereas virtual consoles and serial terminals are managed by driver 4; similarly, both vcs1 and vcsa1 devices are managed by driver 7. The kernel uses the major number at open time to dispatch execution to the appropriate driver.

The minor number is used only by the driver specified by the major number; other parts of the kernel don’t use it, and merely pass it along to the driver. It is common for a driver to control several devices (as shown in the listing); the minor number provides a way for the driver to differentiate among them.

Version 2.4 of the kernel, though, introduced a new (optional) feature, the device file system or devfs. If this file system is used, management of device files is simplified and quite different; on the other hand, the new filesystem brings several user-visible incompatibilities, and as we are writing it has not yet been chosen as a default feature by system distributors. The previous description and the following instructions about adding a new driver and special file assume that devfs is not present. The gap is filled later in this chapter, in “The Device Filesystem”.

When devfs is not being used, adding a new driver to the system means assigning a major number to it. The assignment should be made at driver (module) initialization by calling the following function, defined in <linux/fs.h>:

 int register_chrdev(unsigned int major, const char *name,
      struct file_operations *fops);

The return value indicates success or failure of the operation. A negative return code signals an error; a 0 or positive return code reports successful completion. The major argument is the major number being requested, name is the name of your device, which will appear in /proc/devices, and fops is the pointer to an array of function pointers, used to invoke your driver’s entry points, as explained in “File Operations”, later in this chapter.

The major number is a small integer that serves as the index into a static array of char drivers; “Dynamic Allocation of Major Numbers” later in this chapter explains how to select a major number. The 2.0 kernel supported 128 devices; 2.2 and 2.4 increased that number to 256 (while reserving the values 0 and 255 for future uses). Minor numbers, too, are eight-bit quantities; they aren’t passed to register_chrdev because, as stated, they are only used by the driver itself. There is tremendous pressure from the developer community to increase the number of possible devices supported by the kernel; increasing device numbers to at least 16 bits is a stated goal for the 2.5 development series.

Once the driver has been registered in the kernel table, its operations are associated with the given major number. Whenever an operation is performed on a character device file associated with that major number, the kernel finds and invokes the proper function from the file_operations structure. For this reason, the pointer passed to register_chrdev should point to a global structure within the driver, not to one local to the module’s initialization function.

The next question is how to give programs a name by which they can request your driver. A name must be inserted into the /dev directory and associated with your driver’s major and minor numbers.

The command to create a device node on a filesystem is mknod; superuser privileges are required for this operation. The command takes three arguments in addition to the name of the file being created. For example, the command

 mknod /dev/scull0 c 254 0

creates a char device (c) whose major number is 254 and whose minor number is 0. Minor numbers should be in the range 0 to 255 because, for historical reasons, they are sometimes stored in a single byte. There are sound reasons to extend the range of available minor numbers, but for the time being, the eight-bit limit is still in force.

Please note that once created by mknod, the special device file remains unless it is explicitly deleted, like any information stored on disk. You may want to remove the device created in this example by issuing rm /dev/scull0.

Bash is largely compatible with sh and incorporates useful features from the Korn shell ksh and the C shell csh. It is intended to be a conformant implementation of the IEEE POSIX Shell and Tools portion of the IEEE POSIX specification (IEEE Standard 1003.1). It offers functional improvements over sh for both interactive and programming use.

While the GNU operating system provides other shells, including a version of csh, Bash is the default shell. Like other GNU software, Bash is quite portable. It currently runs on nearly every version of Unix and a few other operating systems – independently-supported ports exist for MS-DOS, OS/2, and Windows platforms.

Physical addressing means that your program actually knows the real layout of RAM. When you access a variable at address 0x8746b3, that’s where it’s really stored in the physical RAM chips.

With virtual addressing, all application memory accesses go to a page table, which then maps from the virtual to the physical address. So every application has its own “private” address space, and no program can read or write to another program’s memory. This is called segmentation.

Virtual addressing has many benefits. It protects programs from crashing each other through poor pointer manipulation, etc. Because each program has its own distinct virtual memory set, no program can read another’s data – this is both a safety and a security plus. Virtual memory also enables paging, where a program’s physical RAM may be stored on a disk (or, now, slower flash) when not in use, then called back when an application attempts to access the page. Also, since only one program may be resident at a particular physical page, in a physical paging system, either a) all programs must be compiled to load at different memory addresses or b) every program must use Position-Independent Code, or c) some sets of programs cannot run simultaneously.

The physical-virtual mapping may be done in software (with hardware support for memory traps) or in pure hardware. Sometimes even the page tables themselves are on a special set of hardware memory. I don’t know off the top of my head which embedded system does what, but every desktop has a hardware TLB (Translation Lookaside Buffer, basically a cache for the virtual-physical mappings) and some now have advanced Memory Mapping Units that help with virtual machines and the like.

The only downsides of virtual memory are added complexity in the hardware implementation and slower performance.

answer is 0000

If array size is specified as 5 in the above program then the program works without any warning/error and prints 5 in C, but causes compilation error in C++.
// Works in C, but compilation error in C++
#include
int main()
{
char arr[5] = “geeks”; // arr[] is not terminated with ”
// and its size is 5
printf(“%d”, sizeof(arr));
getchar();
return 0;
}

When character array is initialized with comma separated list of characters and array size is not specified, compiler doesn’t create extra space for string terminator ‘?. For example, following program prints 5.
#include
int main()
{
char arr[]= {‘g’, ‘e’, ‘e’, ‘k’, ‘s’}; // arr[] is not terminated with ” and its size is 5
printf(“%d”, sizeof(arr));
getchar();
return 0;
}

We can use signal handling in C for this. When Ctrl+C is pressed, SIGINT signal is generated, we can catch this signal and run our defined signal handler. C standard defines following 6 signals in signal.h header file.

SIGABRT – abnormal termination.
SIGFPE – floating point exception.
SIGILL – invalid instruction.
SIGINT – interactive attention request sent to the program.
SIGSEGV – invalid memory access.
SIGTERM – termination request sent to the program.

Additional signals are specified Unix and Unix-like operating systems (such as Linux) defines more than 15 additional signals. See http://en.wikipedia.org/wiki/Unix_signal#POSIX_signals
The standard C library function signal() can be used to set up a handler for any of the above signals.
/* A C program that does not terminate when Ctrl+C is pressed */
#include
#include

/* Signal Handler for SIGINT */
void sigintHandler(int sig_num)
{
/* Reset handler to catch SIGINT next time.
Refer http://en.cppreference.com/w/c/program/signal */
signal(SIGINT, sigintHandler);
printf(“\n Cannot be terminated using Ctrl+C \n”);
fflush(stdout);
}

int main ()
{
/* Set the SIGINT (Ctrl-C) signal handler to sigintHandler
Refer http://en.cppreference.com/w/c/program/signal */
signal(SIGINT, sigintHandler);

/* Infinite loop */
while(1)
{
}
return 0;
}

Ouput: When Ctrl+C was pressed two times

Cannot be terminated using Ctrl+C

Cannot be terminated using Ctrl+C