Linux kernel MD Source code interpretation a

Recently spent some time seriously studying the MD code, and on the basis of the original code to develop a series of new functions, these new features to make MD more complete, more suitable for large storage enterprises, by adding array caching and bitmap optimization greatly improve the storage speed, improve the reliability of the data, In the case of any power off, the data consistency is guaranteed, the Super block is not affected by the array use, completely control the problem of kicking disk, simplifying the user operation. Simply put, there is no threshold for storage. Said so much, actually want to express the meaning of the MD learning is not very smooth, I hereby write this blog with all the brothers and sisters share My learning experience, if you can have a harvest after reading, it is not wasted I work hard to write these technical articles, at the same time your thoughts and reply will be I can continue to write the biggest power.

The MD code, which has been in the kernel tree for more than 10 years, is inseparable from the author Neil Brown, a time-tested open source fighter. Neil Brown's blog address is http://blog.neil.brown.name/, this site is very important, because I found that when I encountered a difficult problem, 80% of questions can be found here, so the time to sweep from head to tail, can solve a lot of " The question of why to do so. "

At first I looked at the kernel code from Module_init began to see, but since the study kconfig, I changed the habit, from Kconfig and makefile began to see the code, if anyone has a better way please share a thank you.

Here's a look at drivers/md/kconfig.

# block  
device driver Configuration  
#  
      
menuconfig MD  
     bool ' Multiple devices driver support (RAID and LVM) "
     depends on blocks  
     help  
       Support Multiple physical spindles through a single logical.  
       Required for RAID and logical volume management.  
      
If MD  
config blk_dev_md  
     tristate "RAID support"
     ---help---  
# ... Omit several  
endif # MD

Menuconfig This word is already familiar, because there is a command make menuconfig when you start to learn to compile the kernel, when we knock down the command in the kernel source directory, a text configuration interface appears. In the text configuration interface, you can choose the module that needs to be compiled into the kernel, then there is the Menuconfig MD, the text configuration interface will have a MD, after the MD, the text configuration interface will appear config BLK_DEV_MD and after the options, these options generally have two states , one is tristate, which means the built-in, module, remove three states, and the other is bool, which means checked or unchecked. Depends on represents a positive dependency, and if this module is selected, then the forward dependent module is automatically selected, and the module on which the forward dependent module recursion is selected. These drive modules are generally selected to be loaded according to the module, which can be easily modified and debugged.

Know the basic configuration of Kconfig, you can customize the kernel on demand, the need to remove all, and understand why sometimes the system lib/module/below why there is no corresponding module.

And for reading the source code, know which source code compiled into the kernel, which source code compiled into the module, which source code is not compiled, so you can read the source code on demand. In addition, there are some compilation options in the source code that are similar:

#ifdef config_*

Code

#endif

Then the * number corresponds to the option that follows the config in the kconfig here, and if this option is selected, then the compilation option is true. These compilation options are also used in the corresponding makefile files, such as the MD corresponding makefile file:

obj-$ (config_md_raid0)          + = raid0.o  
obj-$ (config_md_raid1)          + = raid1.o  
obj-$ (CONFIG_MD_RAID10)          + = RAID10.O  
obj-$ (config_md_raid456)     + = raid456.o  
obj-$ (config_md_multipath)     + = MULTIPATH.O  
obj-$ (config_md_faulty)          + = faulty.o  
obj-$ (CONFIG_BLK_DEV_MD)     + = MD-MOD.O

If the config BLK_DEV_MD is selected in the Kconfig, then makefile will compile the Md-mod.ko module, which file is the module generated by? Look at the definition in makefile:

Md-mod-y + + MD.O BITMAP.O

Raid456-y + + RAID5.O

This means that the config BLK_DEV_MD,MD.C is selected in the Kconfig, and Bitmap.c is compiled. Similarly, config md_raid456 is selected and raid5.c is compiled.

Here, we can also see which module corresponds to which of the several source files.

For example, to load Md-mod.ko, then you need MD.C, bitmap.c. When you modify the RAID5 code, you only need to recompile raid5.c one file.

The next section begins by talking about the MD module initialization.

Source: Http://blog.csdn.net/liumangxiong