plz help me to over come this.

O/P–>block on read or write will definitely occur on server-pro_client side…….

When we use fork( ) to create a child process the child process
does not contain the entire data and code of the parent process.
Then

Does it mean that the child process contains the data and code below the fork( ) call???????

Even this is not so. In actuality the code
never gets duplicated. Linux internally manages to intelligently
share it. As against this, some data is shared, some is not. Till the
time both the processes do not change the value of the variables
they keep getting shared. However, if any of the processes (either
child or parent) attempt to change the value of a variable it is no
longer shared. Instead a new copy of the variable is made for the
process that is attempting to change it. This not only ensures data
integrity but also saves precious memory.

difference between linux and UNIX?

kindly explain from scratch

CHARACTER DRIVER.

Heard so much about Character Driver when i came to Emblogic and now I am working on Character Driver on Linux from last couple of weeks.

Driver – As per my knowledge a Driver is basically a communication medium b/w the application layer and the hardware.
Device Drivers is classified into three basic types: (i) Character driver, (ii) Block driver and (iii)Network driver.

A Character device is one that can be accessed as a stream of bytes i.e. character by character and it sends the data byte by byte to the kernel buffer and user buffer when application give call of write and read respectively.

We use the driver as LKM(Loadable Kernel Module) as it is not essential to keep driver present in the kernel until system is power on. Each module is made up of object code that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program. Whenever we do insmod, the macro ‘module_init’ invokes our initialization routine and module is inserted to the kernel if it is valid. And when we do the rmmod, our module gets removed from the kernel through the macro ‘module_exit’. Our initialization routine registers the driver for the devices and obtains major no. from the registration call int register_chrdev_region(); or int alloc_chrdev_region()); which is defined in the library fs.h . After registering our device, we have to initialize all the resources that are going to be used in our device program. In module_exit, the exact opposite of initialization procedure is performed but in the reverse order. All the resources allocated to the driver will have to be freed . After our module gets inserted successfully onto the kernel,it can be seen in /proc/modules file.

We develop Charater Driver because it is most suitable for simple Hardware devices.
For implementing my character driver, we have used SCULL (Simple Character Utility for Loading Localities) because of its advantage that it does not depend upon hardwre. Scull is just some memory which is allocated from the kernel. We have defined the behaviour of the system calls for the device. We have used cdev_init and cdev_add functions to initialize the struct cdev. Struct cdev is the actual representation of the device.
Next step is to map the system calls with the routines written in my character driver. In our open routine,we are checking the mode and depending on that mode, we are performing some specific tasks . In the open routine we mappthe scull to the device by using the macro ‘container_of’. The return value of container_of will be starting address of mapped memory that we will use to read and write on device and we store this address in the private_data of the struct file structure defined in fs.h library. The difference between the kmalloc and container_of macro is that using kmalloc, the memory is allocated in the RAM but container_of macro maps the maps the scull into the device.

Write Data & Read Data.
In our write routine we write the data from application to the device via scull quantum by using copy_from_user() function. Write routine also checks for the offset value (file position) where the application wants to write.
In read routine we read the data from the device via scull quantum by using copy_to_user() function. Read routine also checks for the offset value from where application wants to read.
We have also implemented lseek routine that sets the offset value as provided by the application in lseek system call.

Now the time has come to test the driver.
(i) Compile and insert our module in running kernel dynamically. This is done byinsmod on shell here lkm is my name of c file of driver.Compilation of the file should be by Makefile.

(ii)To make communication possible between application application and device driver,we require node in (VFS).
Node is created by the command “mknod node_name c major no. minor no.”, where c specifies that it is for character driver.

(iii)After testing we should have to remove the module from kernel with command “rmmod” like rmmod lkm to free the allocated major number.

Character driver though while working was not an easy task to accomplish but with guidance of Sir and fellow friends it was a great experience.

                                                                           SUBMITTED TO:  Mr. PRAVJOT SINGH                                  LINUX DEVICE DRIVERS  

v  ARTICLE ON CHARACTER DRIVER:

THIS  ARTICLE   IS ALL ABOUT  TO  THE CONCEPTS  THAT  I HAVE  LEARNED  AND  MAINLY  CONCERNED TO THE WORK  WHATEVER  I HAVE PERFORMED  IN THE PROJECT  REGARDING ASSIGNMENT IN ORDER  TO  SUCCESSFUL  COMPLETION OF TRAINING.

v  INTRODUCTION OF CHARACTER DRIVER:

AS THE  NAME  SUGGESTS  ,THE DEVICE -DRIVER  PROVIDES THE MECHANISM  TO  DRIVE THE  HARDWARE(DEVICE)  ACCORDING  TO  THE  APPLICTION.THE TYPE & CATEGORY   OF THE DRIVER  IS DEPENDENT  ON  THE  TYPE &  REQUIREMENT OF APPLICATION  WHICH  WEAREUSING. WHICH MEANS TOSAYTHAT  TO ACCESS  THE  PENDRIVE WE NEED USB  DRIVER  ,FOR BTLUETOOTH WE WE NEED BT DRIVER & FOR  MEDIA  PLAYER  WE  NEED  A  SEPRATE ONE.  DIFFERENT TYPES OF APPLICATION  REQUIRES   DIFFERENT  TYPE  OF  DRIVERS.

CHARACTER DRIVER WORKS FOR CHARACTER DEVICES   WHICH  CAN BE ACCESSED AS STREAM OF BYTES. SUCH DRIVER USUALLY IMPLEMENTS OPEN, WRITE,  READ  &  CLOSE  SYSTEM  CALLS.

I think One of the good features of Linux is the ability to extend at runtime the set of features offered by the kernel. This means that you can add modules to the kernel (and remove modules as well) while the system is up and running. The need of using device drivers is to increase the functionality of kernel . Each piece of code that can be added to the kernel at runtime is called a module. Each module is made up of piece of codes that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program.

Currently I am working on character driver & its practical implementation. In this article I am going to discuss what i know about character driver briefly.

Now as I have to make my driver capable of directly handshake-able with the kernel so it was essential to work in kernel space instead of user space ,so i have to use the kernel libraries(like kernel.h, init.h ,fs.h etc..) instead of glibc libraries(like stdio.h,stdlib.h,fcntl.h etc…).

v  HOW   TO   IMPLEMENT?

• I AM GOING TO DESCRIBE THE BASIC  STEPS WHICH  I  HAVE  FOLLOWED WHILE  IMPLEMENTING CHARACTER DRIVER:

–     I started to write the program  using two predefined macros named as module_init (entry_function) and module_exit(exit_function) as entrance point as main() in user space and exit point respectively.In which I have written my own start &  end function. So after executing module_init execution will start from my function where I have to specify the major number and name of our driver, capacity to handle maximum number of device at a time and maximum memory of the driver. The major number identifies the driver associated with the device. I am firstly allocating major number to my driver which is basically a highest possible integer value between 0 to 255 by which our driver will be known in the kernel like other device drivers as stored in /proc/devices file .We can select major number for our driver from previously mentioned path but generally we privilege kernel to select major number because kernel will allocate it dynamically .This can be done with the register_chrdev_region() function call defined in fs.h  which is in kernel library .In current scenario register_allok_chardev_region is in trend to do the errlier mentioned task .This will give the result of 32 bit(12 + 20 bit) at the address as give in first argument of call. After that I have used the first 12 bit i.e major number but i specify my own minor number generally 0 to upward in MKDEV() macro defined in kdev_t.h. After that I have allocated memory to sculldev structure(user defined structure that contain all information of the driver)) & separately initialized all its members as sculldev initialization function .Now used the cdev_init() and cdev_add() to initialize and add the cdev structure for our device which will contains the device specifications. Now I have written separate functions for each ( to create scullQsets structures, create q-sets structures, create quantums)& called these functions from write & read functions of driver modules to perform the desired operations in device.

In order to perform various operations like open, write, read, lseek and close file I have written an application in  user space & mapped it similar kind if file operations (open, write read, llseek, release)that is in my driver program .So i have mapped these system calls in struct file_operations structure with my respective open,write,read,lseek and close functions according to prototype defined in <fs.h> kernel header file that will now handles the application calls instead of drivers of the OS.

But Before doing anything we have to map our allocated memory with the device memory this is done in the open function of driver with

container_of(ptr, type, member) in which first argument is pointer to i_cdev member of struct inode,2nd argument is user defined structure which contains pointer to struct cdev and third argument is pointer to struct cdev.Actually struct cdev is actual representation of the device. Now return of container_of will be starting address of mapped memory that we will use to read and write on device and i store this address in the private_data of the struct file structure defined in fs.h library.

After doing this now i have made my read, write and lseek function compatible with the almost all type of requests from application.In this write function will store the written data in own quantums when write request comes and give back that data according to the read request of application.I have also handled the single multithreaded application.

Now to test this driver we have to compile and insert our module in running kernel dynamically. This is done with command insmod ./modules/program name(without .c).ko  & Compilation of the file should be by Makefile. After completion of work (successful insertion & execution of task) we have to remove our module this is done by command rmmod  program name(without .c).

If every step is correct & written in proper manner then  program will run & it will give desired result otherwise kernel will be crashed.

REMARKS: THERE MAY BE  POSSIBILITY OF ERROR IN SYNTEX, SENTENCES,ARGUMENTS (& SOME-WHAT IN CONCEPTS ALSO ). SO ANY COMMENT, CORRECTION, SUGGESTION  IS CORDIONLY INVITED.

REGARD’S

RANA BRIJENDRA SINGH

I have been working upon Device Driver (Character Driver, to be specific) since last 20 days.Before start working, First of all I needed to know what really a device driver is? As we all know it is the kernel what is directly going to interact with the Hardware and if our application need to access the hardware we need a driver(Specific one for a class of devices)for that in kernel space. As the name suggest a Device Driver is a LKM(Loadable Kernel Module) which drives(runs) our device.Drivers are of two types, Static and Dynamic. One i am going to develop will be dynamic i.e it will be removed from kernel when not needed any more. The good thing about a Moduler kernel is a Module can be inserted and removed from the running kernel(using kernel utilities insmod and rmmod respectively). There are three types of devices i.e Character devices like printers, Block devices like Mass storage devices and Network devices like USB modem etc. Now a Character driver is a driver developed to handle character devices.
Now lets explain the basic arch. of a character driver. Memory of our system is divided in to two parts User space and kernel space. Our applications runs in the user space and our driver runs in kernel space. An application cant see anything in kernel space.Driver is just like a black box for the application developer. So if the application need to access the kernel space, it need a fifo in the VFS(Virtual File System) layer. We create this for the specific device using mknod. In kernel space a driver is identified by its unique 12bit major number and a device is identified by its unique 20bit minor number. This 32bit unique number is called dev id(device id). This 32bit no is obtained for a device using a kernel MACRO i.e alloc_chrdev_region(). This registration is to be done right after inserting our module in to the kernel and it should also be unregistered before removing the module.
There are four most important structures, knowing about those was very much needed. First one is struct cdev. This structure is the representation of a character device in the kernel. This one have a lot of hardware specific information of the device. its most important members are dev(for dev id),owner(owner of the device, the module itself) and *fops (pointer to the struct file_operations). Second one in struct file_operations which is a collection of function pointers, each of the function is routine for performing a specific operation over the device like read, write ,open, close etc. Another one is struct inode(for the device file). We all know everything in linux is treated as a file, some are regular files and some are special files. A character device is treated as a special file in our system. Attributes of a file are stored in the structure struct inode and struct inode i am talking about have attributes of that special character device file. Fourth one is struct file. struct file is a structure which contains the attributes of a stream. This stream is a stream created between our app and node in vfs, when we give an open call from app.
I have allocated some memory in the kernel space of my RAM in form of SCULL(Simple Character Utility for Loading Localities), which i am treating as a device. This memory is variable as i will be performing write and read, it will be allocated and deallocated accordingly. Starting node of this memory is ScullDev which will be loaded with the lot of info about the device like device_size, data_size, quantum_size, qset_size, write_count and the most important an object of struct cdev. We need to initialize and add this cdev object as our device in the kernel using two MACROS cdev_init() and cdev_add(). cdev_init will initialize our object for the set of operations and cdev_add will add this device in to the device table.
After all this, my device is ready to be worked upon i.e open,write,read,close. For this it was required to map my driver routines to the routines called by system as when a call is given from app my routines should run in the driver. This mapping is to be done in struct file_operations by giving the addresses of my_routines to corresponding function pointers in fops. In open i fetched the address of my ScullDev for the perticular cdev and stored it in private_data field of a system generated structure struct file pointed by *filep in open for the future use of this address in write and read.
Now i am able to write data to the multiple quantums, multiple scullqset in trunc as well as append mode. I am able to read from the same as well. lseek is also done, and i am testing my driver for multithreaded apps.

I am working on Character Driver on Linux from last few days.Device Driver is simply a piece of code as a part of kernel,dynamic (temporary) or static (permanent) required to make the hardware accessible to the application. Device Drivers can be classified into three basic types: Character driver, Block driver and Network driver. A character device is one that can be accessed as a stream of bytes i.e. character by character. And code needed make communication possible b/w a character device and application is character driver.
As there is a very good feature of Linux i.e. the ability to extend the set of features offered by the kernel at runtime. This means that we can add functionality to the kernel (and remove functionality as well) while the system is up and running. Each piece of code that can be added to the kernel at runtime is called a module. Different types (or classes) of modules,that can be inserted to the Linux kernel includes device drivers but not limited to this. Each module is made up of object code that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program. Whenever we do insmod, the macro ‘module_init’ invokes our initialization routine and module is inserted to the kernel if it is valid. And when rmmod is done our module gets removed from the kernel through the macro ‘module_exit’. Our initialization routine registers the driver for the devices and obtains major no. from the registration call( int register_chrdev_region(dev_t first, unsigned int count, char *name); or int alloc_chrdev_region(dev_t *dev, unsigned int firstminor, unsigned int count, char *name);) and sets up some basic parameters we’ll be using ahead e.g struct ScullDev’s elements. Also we have to initialize the resources that are going to be used.In module_exit the opposite of initialization procedure is performed in reverse order.All the resources allocated to the driver to be freed and this is done by exit routine.After our module gets inserted successfully to the kernel,it can be seen in ‘/proc/modules’ file.And if we are able to register our driver successfully, we can see the driver’s name in ‘/proc/devices’ file.
To implement our character driver we have used SCULL (Simple Character Utility for Loading Localities). Scull acts on a memory as though it were a device.The advantage of scull is that it isn’t hardware dependent. Scull just acts on some memory, allocated from the kernel. Anyone can compile and run scull.We have mapped the system calls to the routines written in our own driver i.e. we have defined the behaviour of the system calls for a particular device. We have used cdev_init and cdev_add functions to initialize the struct cdev and inform the kernel about the device. In our open routine,we are checking the mode,the device is trying to being opened. And depending on that mode flags we are performing some specific tasks e.g. if device is opened in write only mode then the device memory will get trimmed before going ahead.In trimming routine we just free all the memory allocated to the scull. Also in open routine we are mapping the scull to the device by using the macro ‘container_of’.In brief it simply maps the scull into the device and returns a pointer to the memory of device having scull mapped onto it.And we have stored this pointer into the void pointer ‘filep->private_data’ to preserve the starting address of device memory for further use. In our write routine we are writing the data from application to the device through the scull quantums by using ‘copy_from_user’.Write routine also checks for the offset value i.e. cursor position where application wants to write.In read routine we are copying data from the device through scull quantums using ‘copy_to_user’ function.Read routine also checks for the offset value from where application wants to read. We have also implemented lseek routine that sets the offset value as provided by the application in lseek system call.And finally in release routine we have just released the resources used after opening the device.