•  Block Drivers are act as conduit between core memory and secondary storage.
• There is a virtual memory layer between core memory and secondary storage.
• Block Layer could be seen as a part of virtual memory subsystem.
• Block driver provides access to devices that transfer randomly accessible data.
• Block Driver controls the block layer, makes decision about collecting bytes into group of bytes, handle interaction between virtual layer and block layer, block layer and block devices.
• Block Driver collect chunks of bytes into blocks.
• As almost every block device consist of file system also. Therefore block device driver must take care of file system.

Both the times the file was saved in the system but only difference is that for the first observation the file was saved in you primary memory and the second time you just saved your file in the secondary storage.

Who did this stuff? The answer is block layer of the Operating system.

This is just a example to understand what is the role of Block layer of the Operating System but there are too many stuffs in the operating system where the block driver works. To implement the block driver we can simply have a conclusion i.e. whenever we need to save the primary storage data into the secondary storage or to fetch the data stored in the secondary storage into the primary one, the block layer comes into the picture.

The block driver simply writes the block of bytes into the secondary storage from the primary storage or reads the block of bytes from secodary storage to the primary storage.

The block driver deals with the data in fixed size of blocks. Mostly all the devices which are used as the secondary storage are the block devices.

We require to mount a filesystem on the block devices. Filesystem provides the way of arrangment in the device and meaning of the simple 0s and 1s(raw data stored on the device) to the Operating System. The device file provides the interface between the filesystem and the block device driver. Filesystem can divide the disk (Mostly the secondary storage) into multiple logical parts i.e. partitions of the disk.

Block devices support random access and generally use buffered input and output routines. The operating system allocates a data buffer to hold a single block each for input and output. When a program sends a request to read data from, or write data to, the device, the system stores each character of that data in the appropriate buffer. When the buffer fills up, the appropriate operation takes place (data transfer) and the system clears the buffer.

The sector is the smallest addressable unit of the disk. Each sector stores a fixed amount of user-accessible data, traditionally 512 bytes for hard drives and 2048 bytes for CD-ROMs and DVD-ROMs. Newer hard drives use 4096-byte sectors.

When Unix was written 25 years ago, its design was eclectic. One unusual design feature was that every physical device connected to the computer was represented as a file. This was a bold decision, because many devices are very different from one another, especially at first glance. Why use the same interface to talk to a printer as to talk to a disk drive?

The short answer is that while the devices are very much different, they can be thought of as having most of the same characteristics as files. The entire system is then kept smaller and simpler by only using one interface with a few extensions.

This is fine, except that it hides important differences between devices. For example, it is possible to read any byte on a disk at any time, but it is only possible to read the next byte from a terminal.

There are other differences, but this is the most fundamental one: Some devices (like disks) are random-access, and others (like terminals) are sequential-access. Of course, it is possible to pretend that a random-access device is a sequential-access device, but it doesn’t work the other way around.

A practical effect of the difference is that file systems can only be mounted on block devices, not on character ones. For example, most tapes are character devices. It is possible to copy the contents of a raw, quiescent (unmounted and not being modified) file system to a tape, but you will not be able to mount the tape, even though it contains the same information as the disk.

Most textbooks and tutorials start by explaining character devices, the sequential-access ones, because a minimal character device driver is easier to write than a minimal block device driver. My own Linux Kernel Hackers’ Guide (the KHG) is written the same way.

My reason for starting this column with block devices, the random-access devices, is that the KHG explains simple character devices better than it does block devices, and I think that there is a greater need for information on block devices right now. Furthermore, real character device drivers can be quite complex, just as complex as block device drivers, and fewer people know how to write block device drivers.

I am not going to give a complete example of a device driver here. I am going to explain the important parts, and let you discover the rest by examining the Linux source code. Reading this article and the ramdisk driver (drivers/block/ramdisk.c), and possibly some parts of the KHG, should make it possible for you to write a simple, non-interrupt-driven block device driver, good enough to mount a filesystem on. To write an interrupt-driven driver, read drivers/block/hd.c, the AT hard disk driver, and follow along. I’ve included a few hints in this article, as well.

The Heart of the Driver

Whereas character device drivers provide procedures for directly reading and writing data from and to the device they drive, block devices do not. Instead, they provide a single request() procedure which is used for both reading and writing. There are generic block_read() and block_write() procedures which know how to call the request() procedure, but all you need to know about those functions is to place a reference to them in the right place, and that will be covered later.

The request() procedure (perhaps surprisingly for a function designed to do I/O) takes no arguments and returns void. Instead of explicit input and return values, it looks at a queue of requests for I/O, and processes the requests one at a time, in order. (The requests have already been sorted by the time the request() function reads the queue.) When it is called, if it is not interrupt-driven, it processes requests for blocks to be read from the device, until it has exhausted all pending requests. (Normally, there will be only one request in the queue, but the request() procedure should check until it is empty. Note that other requests may be added to the queue by other processes while the current request is being processed.)

On the other hand, if the device is interrupt-driven, the request() procedure will usually schedule an interrupt to take place, and then let the interrupt handling procedure call end_request() (more on end_request() later) and then call the request() procedure again to schedule the next request (if any) to be processed.

#include”header.h”

dev_t dev;

void bulk_request(struct request_queue *q)

{
struct request *req;

req = blk_fetch_request(q);

while (req != NULL)
{

if (req == NULL || (req->cmd_type != REQ_TYPE_FS))
{
printk (KERN_NOTICE “Skip non-CMD request\n”);
__blk_end_request_all(req, -EIO);
continue;

}

}
}

int __init start(void)
{
//int reg;

// struct request *disk;

static struct request_queue *Queue;

printk(KERN_INFO “Begin : %s\n”,__func__);

printk(KERN_INFO” HELLO KERNEL”);
sbullmajor=register_blkdev(sbullmajor,device_name);

if(sbullmajor)
{

#ifdef DEBUG

printk(KERN_INFO ” Registration Sucessful\n “);

printk(KERN_INFO”Major no is %d\n”,sbullmajor);

#endif

}
else

{

#ifdef DEBUG

printk(KERN_INFO “Registartion failed\n “);

#endif
}
sbulldev=kmalloc(sizeof(struct Sbulldev),GFP_KERNEL);

memset(sbulldev,”,sizeof(struct Sbulldev));

sbulldev->size=hardsect_size;

sbulldev->data=vmalloc(sbulldev->size);

if(sbulldev->data ==NULL )

{
#ifdef DEBUG
printk(KERN_INFO ” Memory allocation failed\n “);

#endif

}
else

{
#ifdef DEBUG

printk(KERN_INFO ” Memory allocation of block device sucessful\n “);

#endif
}

spin_lock_init(&sbulldev->lock);

#ifdef DEBUG
printk(KERN_INFO ” after spin_lock\n “);

#endif
sbulldev->gd=alloc_disk(16);

if(sbulldev->gd==NULL){ //no of minors is 1 no partioning;

#ifdef DEBUG
printk(KERN_INFO ” alloc_disk failed\n “);

#endif

goto OUT;

}

else

{
#ifdef DEBUG

printk(KERN_INFO ” alloc_disk sucessful\n “);

#endif
}
Queue=blk_init_queue(bulk_request,NULL);

blk_queue_logical_block_size(Queue,hardsect_size);

sbulldev->gd->major=sbullmajor;

#ifdef DEBUG

printk(KERN_INFO ” sbullmajor\n “);

#endif

sbulldev->gd->minors=sbullminor;
#ifdef DEBUG

printk(KERN_INFO ” sbullminor\n “);

#endif

sbulldev->gd->first_minor=1;

#ifdef DEBUG

printk(KERN_INFO ” first_minor\n “);

#endif

sbulldev->gd->fops=f_ops;

#ifdef DEBUG

printk(KERN_INFO ” file_operations\n “);

#endif

sbulldev->gd->queue=Queue;

#ifdef DEBUG

printk(KERN_INFO ” Queue\n “);

#endif

sbulldev->gd->private_data=sbulldev;

#ifdef DEBUG

printk(KERN_INFO ” private_data\n “);

#endif

strcpy(sbulldev->gd->disk_name ,”sbulla” );

#ifdef DEBUG

printk(KERN_INFO ” sbulla\n “);

#endif

set_capacity(sbulldev->gd,hardsect_size);

#ifdef DEBUG

printk(KERN_INFO ” set_capacity\n “);

#endif
add_disk(sbulldev->gd);

#ifdef DEBUG

printk(KERN_INFO ” add disk\n “);

#endif

#ifdef DEBUG

printk(KERN_INFO ” End of %s\n “,__func__);

#endif

OUT:

return -1;

return 0;

}
void __exit release(void)
{

//int i;

#ifdef DEBUG

printk(KERN_INFO “exit : %s\n”,__func__);

#endif
del_gendisk(sbulldev->gd);

printk(KERN_INFO ” add disk\n “);

blk_cleanup_queue(sbulldev->queue);

printk(KERN_INFO ” add disk\n “);

//put_disk(sbulldev->gd);

 
unregister_blkdev(sbullmajor,device_name);
printk(KERN_INFO “BYE KERNEL”);
}
module_init(start);

module_exit(release);

}

the driver crashes  moment insmod ./modules/lkm.ko is done…..ha i have zero bytes of home drive  does this effect