Device driver is a software implemented part of the kernel to provide a interface or interaction between hardware and file system , Device driver runs in kernel space as a part of kernel , which can be load and unload on demand , so these type of device driver are known as dynamically loaded modules.

Driver can be insert in kernel as a module using insmod and can be remove using rmmod these are two basic commands. Though in this article i am going to discuss about char driver that i have implemented.

Implementation :

In my character driver first of all i registered my char driver using

int alloc_chrdev_region(dev_t *, unsigned, unsigned, const char *);

Unregistered using the follwing function –

void unregister_chrdev_region(dev_t, unsigned);

Till here my driver got least available major number allocated by kernel you can see by doing

cat /proc/devices after inserting the lkm. Now my next task was to add a number devices to my driver and provide them minor number i done this using macro called MKDEV(MAJOR, MINOR). So till here i have allocated major and minor number and registered my char driver with my kernel .

My next task was to create an application in user space and performing read write operation by that application at a specific node that was created by me in file system using node creating command .

mknod node c mjorno minorno

this will create a character driver node in user space our application will be performing read and write operation on this node .

Mapping System calls :

scull_open :

this was the main task to map the read and write operation of application to our driver so when the application gives a system call open() , then our mapped open starts and return a file descriptor to the application .

int scull_open(struct inode *inodep, struct file *filep) ;

scull_read :

After opening the device we need to perform read peration on that device so we need to map

our read and write also by using this callback function.

ssize_t scull_read(struct file *filep, char __user *ubuff, size_t size, loff _t *loff) ;

scull_write :

After opening the device we need to perform write operation on that device so we need to map

our read and write also by using this callback function.

ssize_t scull_write(struct file *filep, char __user *ubuff, size_t size, loff _t *loff) ;

scull_release :

When the application give the call to close the file descriptor then our mapped callback function starts.

int scull_release(struct inode *inodep, struct file *filep) ;

Other operations :

I implemented some more operations like ioctl operation used for debugging perpose :

long scull_ioctl(struct file *, unsigned int, unsigned long) ;

And lseek opeartion were also implemented

loff_t scull_llseek(struct file *, loff_t, int);

Device for operations :

Since we were not having any device so for that I have created a memory area on RAM that

was tread as a device memory , I named it SCULL .

Thank YOU

Overview :

Hi all This project is regarding Inter-process Communication techniques in this project ,

Before explaining IPC i must let you know why we need these type of techniques .

In user space each process have its own separated address space. Suppose if any process wants to send any information or data to the another process which is running in different address space then we need these IPC techniques to communicate among the processes .

I have learned following techniques and some of them was synchronization techniques .

Like Pipes , FIFO (known as named pipes also), message queues , shared memory .

And synchronization techniques was Semaphore and a little bit about Mutex.

On the basis of these learned techniques I developed some projects , In my projects

there was a main process that is i called Server program.

To this main server there was three requesting clients and corresponding to these requesting clients there was three processing clients. Every requesting and every processing client was connected to the main server program .

All the requesting clients was sending the request and data to the main server program for the request were very simple like to add ,subtract ,multiply the numbers . This data was getting by the server program continuously an the corresponding request sent to the processing clients .

The processing was adding , subtracting, multiplying the data(numbers).

And the corresponding results was sent to the server .the result sent by the processing clients further sent to requesting clients.

For the communication between the process i used the techniques learned by me. As

i have explained in the beginning of my article , In my first project i used three pipes at requesting client and server side and same at server and processing clients side.

In my later projects i replaced pipes from FIFO and in the next projects FIFO was replaced by Message queues and shared memory .But when i was writing the code i faced some concurrency (synchronization) issues .To resolve these issues i used semaphores in all my projects .

Lets go inside my projects

Project Internals :

First off all i created six pipe in server program for each child process these child process was created using a process duplication function that is fork() and now i was having six child process each having its own PID(process id ).Now my next task was to replace these child process from my own written requesting and processing clients .

That i have done use process replacement system call execv() . In this call i passed read and write file descriptor obtained from pipe(fd) system call as an argument to the excev() call .

I done the same for all clients by doing this my all requesting and processing clients was running independently .with the same PID of the child .

Now my next task was to start communication between the processes .

All the requesting clients were sending the data to the server using write file descriptor that was sent by the server ,to send data i used write() system call.

Corresponding to this there was in the server a read() was waiting for the data.

There was a condition of block on read ,until and unless writer writes the data on pipe.

In the data writer was sending two operand and one operator .Server was checking the operand and in its data base maintained by the server and invoking the corresponding processing client .After invoking processing client the server was sending the data using write() system call .

And was waiting for the result using read() system call .Here was also block on read condition.

To prevent from Zombies and oprphan process and used a function wait(pid) .So the main server does not terminate until its child does not terminate properly.

Issues faced :

I faced many issues some of them are listed below -

• I faced synchronization problem ,actually when ever i was sending the data from requesting clients it was reading back its first byte as the result , without waiting for the result .

  So in the server program i was getting only 2 byte of data as 1 byte we have lost .

  So to block the requesting client until server read the requested data i used semaphores.

  A famous synchronization technique.

Thank You