EmbLogic's Blog

An Article On Character Driver

The major issue faced by the kernel today is that it has become blotted. So the concept of modularity has been introduced into the kernel programming so that a required module could be loaded into it dynamically.The driver I used to access a device is a character driver which has the property to access a device, character by character. A infinite stream of byte, they provide an unstructured access to the hardware. This device driver is loaded into a kernel space dynamically by using insmod command .After this a dynamic loader comes into play which links the unresolved symbol in the module to the symbol table in the kernel.

INITIALISATION: When a new module is introduced in a kernel it does not know by itself that for what this module is for. Thereby it run it’s initializing function which is called by module_init().That allow the module to register itself to the each and every facility that the module support. In case of device driver it has to allocate , initialize and register a structure for a category of a device that it has to use, specific to character driver this is done by initializing a cdev structure and implementing a file_operations.

EXIT: The delete_module system call calls a function name module_exit() before removing the kernel from a module. The kernel ensure that the device module is not used by any other and the allow it to get removed.

 

As each and every device in the kernel is identified by a unique number which of type dev_t and it’s an 32 bit value which enclose the (major,minor) number in itself. So,the very first task for our is to ask for a dev number from a kernel so that it could recognise our device when it is in action.

MAJOR=Specific to driver,

MINOR=Specific to device,

This is fetch while registration than the second important task is to initialise our device and at this instant we can say that our device has become alive and the next is to add it to character device database.

This is done by cdev_add. cdev_add basically adds the device to the system. What it means essentially is that after the cdev_add operation your new device will get visibility through the /sys/ file system. The function does all the necessary house keeping activities related to that particularly the kobj reference to your device will get inserted at its position in the object hierarchy.

If we have an device with you we can develop driver accordingly and as far as testing is concerned we initiated it by defining a structure named Scull_dev. That have supposed to used a memory on RAM as virtualization of device.

The next objective is to define a device file specific operations that can be manipulated in struct file_operations:

open: To open the device,

close: To close the device,

read: To do an input operations,

write: To do write operations,

and many more as required.

As the device is open using a character driver node which can be consider as an entry point of the device by using mknod -c major minor. Now the device is accessible from the user space. And it’s different system call is mapped to our device routine for the specific device.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>