Transferred from: http://blog.chinaunix.net/uid-15724196-id-128140.html
2nd Chapter
+---------------------------------------------------+
| Write a block device driver |
+---------------------------------------------------+
| Zhao Lei |
| Email[email protected]|
+---------------------------------------------------+
| The copyright of the article belongs to the original author. |
| You are free to reprint this article, but the original copyright information must be retained.
| For commercial use, be sure to contact the original author if you have not obtained |
| Copyright disputes arising from the authorization shall be the sole responsibility of the infringer.
+---------------------------------------------------+
The previous chapter not only implements one of the simplest block device drivers, but may also be successful in scaring off many readers who are ready to continue watching.
Because the first chapter seems too difficult.
But readers should not complain too much about the author, for the first time in most cases is not a good experience ...
For the readers who stick to this chapter, we have prepared some simple content to reward you.
The relationship between the block device and the I/O Scheduler has been mentioned in the previous chapter.
The I/O Scheduler can increase the order of block device access by merging requests, rearrange the order of block device operations, and so on.
It's like eating a big row of street stalls, and if you dot an unpopular breed, it might wait longer,
And if the point is exactly the same as the point on the table next to the same, then will soon come up, because the chef probably simply fired together.
However, I/O Scheduler and block device situation there are some subtle differences, probably can be likened to someone else ordered a tomato and egg soup you then ordered a tomato scrambled eggs.
The smart chef will make your dish first, because you can then add water to the pot, and the person who drinks it first is your water.
Two dishes one pot performance on a block device can be likened to the same location of the block device, which is not related to the I/O Scheduler, you can think of this when learning the Linux cache strategy.
A girl changed a lot of clothes to ask me to drift not beautiful, and my evaluation as long as a glance can be taken out.
The other party always feel that clothes to brand good, good fabric, collocation reasonable, to meet the temperament of the individual, to have culture, and my standards are simple: the thinner the better.
The so-called odor is congenial, I write the block device driver requirements for I/O Scheduler is probably the same.
The reason is not because the block device driver is lustful, but the data in this so-called block device is in memory.
This also means that our "block devices" read and write quickly and do not have the usual seek time for devices such as disks.
Therefore, for this "block device", a complex I/O Scheduler not only does not play the slightest role, but it itself will be wasted a lot of memory and CPU.
The same is true for SSDs, USB drives, memory sticks and the like. When SSDs become popular in the future, it's probably the day the I/O scheduler dies.
Here we try to select one of the simplest I/O schedulers for our block device driver.
Currently, Linux contains 4 I/O schedulers, anticipatory, CFQ, Deadline, and NoOp.
Linux before 2.6.18 uses anticipatory by default, and CFQ is used later by default.
About the principles and features of these 4 schedulers we are not going to introduce here because the relevant introductions are all over the net.
But we still can't avoid mentioning the NoOp scheduler here, because we're going to use it right away.
NoOp, as the name implies, is a largely non-director of the scheduler. It basically does not do any additional processing of the request, just to tell the general-purpose block device layer: I finished processing.
But unlike public servants who have rates, the existence of NoOp is still quite progressive. At least we need an I/O scheduler that doesn't have to be messed up right now.
Selecting a specified I/O scheduler requires this function:
int elevator_init (struct request_queue *q, char *name);
Q is a pointer to the request queue, name is the I/O scheduler that needs to be set.
If name is null, the kernel first attempts to select the scheduler specified in the startup parameter "Elevator=".
If you don't succeed, choose the default scheduler you specified when compiling the kernel.
If luck is too bad or unsuccessful, choose the "NoOp" scheduler.
Don't ask me how I know, everything is in RTFSC (Read the f**ing Source Code--linus Torvalds).
For our code, it is added after simp_blkdev_queue = Blk_init_queue (Simp_blkdev_do_request, NULL):
Elevator_init (Simp_blkdev_queue, "NoOp");
But the problem is that the system has already applied for us in the Blk_init_queue () function, so we need to take a little trouble here and send the old one back.
So our code should be:
At the beginning of the Simp_blkdev_init () function:
elevator_t *old_e;
After the Blk_init_queue () function:
Old_e = simp_blkdev_queue->elevator;
if (Is_err_value (Elevator_init (Simp_blkdev_queue, "NoOp")))
PRINTK (kern_warning "Switch elevator failed, using default\n");
Else
Elevator_exit (old_e);
To facilitate reading and improve the occupancy rate of this article in Google Disk, we give the entire modified Simp_blkdev_init () function:
static int __init simp_blkdev_init (void)
{
int ret;
elevator_t *old_e;
Simp_blkdev_queue = Blk_init_queue (Simp_blkdev_do_request, NULL);
if (!simp_blkdev_queue) {
ret =-enomem;
Goto Err_init_queue;
}
Old_e = simp_blkdev_queue->elevator;
if (Is_err_value (Elevator_init (Simp_blkdev_queue, "NoOp")))
PRINTK (kern_warning "Switch elevator failed, using default\n");
Else
Elevator_exit (old_e);
Simp_blkdev_disk = Alloc_disk (1);
if (!simp_blkdev_disk) {
ret =-enomem;
Goto Err_alloc_disk;
}
strcpy (Simp_blkdev_disk->disk_name, simp_blkdev_diskname);
Simp_blkdev_disk->major = Simp_blkdev_devicemajor;
Simp_blkdev_disk->first_minor = 0;
Simp_blkdev_disk->fops = &simp_blkdev_fops;
Simp_blkdev_disk->queue = Simp_blkdev_queue;
Set_capacity (Simp_blkdev_disk, simp_blkdev_bytes>>9);
Add_disk (Simp_blkdev_disk);
return 0;
Err_alloc_disk:
Blk_cleanup_queue (Simp_blkdev_queue);
Err_init_queue:
return ret;
}
The changes in this chapter are small, so let's test this code:
First, we compile the module and load it as it was originally:
# make
Make-c/lib/modules/2.6.18-53.el5/build SUBDIRS=/ROOT/TEST/SIMP_BLKDEV/SIMP_BLKDEV_STEP2 Modules
MAKE[1]: Entering directory '/usr/src/kernels/2.6.18-53.el5-i686 '
CC [M]/root/test/simp_blkdev/simp_blkdev_step2/simp_blkdev.o
Building modules, Stage 2.
Modpost
cc/root/test/simp_blkdev/simp_blkdev_step2/simp_blkdev.mod.o
LD [M]/root/test/simp_blkdev/simp_blkdev_step2/simp_blkdev.ko
MAKE[1]: Leaving directory '/usr/src/kernels/2.6.18-53.el5-i686 '
# Insmod Simp_blkdev.ko
#
Then take a look at the I/O scheduler that our block device now uses:
# Cat/sys/block/simp_blkdev/queue/scheduler
[NoOp] Anticipatory deadline CFQ
#
It seems to be a success.
Oh, the previous chapter forgot to look at the old program Scheduler information, here to fill the old program situation:
# Cat/sys/block/simp_blkdev/queue/scheduler
NoOp anticipatory deadline [CFQ]
#
OK, let's complete a simple chapter and use the facts to show that the author did not lie at the beginning.
Of course, the author also tries to make the next chapters easier to read than fiction.
< not finished, to be continued >
