Quest Linux: From partition table to block device - I am not a table, I am a block device

About the author: Huang weller (Huang Weller), graduated from Suzhou University, worked in Suzhou Bosch Automotive Components Automotive Multimedia Division, engaged in the development of platform for automotive multimedia entertainment systems for more than six years, and has been in contact with Linux for nearly 10 years. Interested in Linux system performance optimization, multimedia frameworks, file systems and storage devices, USB and virtualization.

Our study habits are basically from shallow to deep , for example, we first learn how to use the fdisk tool to partition the disk , then I want to see what fdisk has done to the disk , and see other partitions besides fdisk for a long time. Tools can partition the disk . Usually we only need to know how to use it . There are also many reasons for us to think about what is happening behind it . These reasons may be that you have encountered specific problems and have to let you go . Going to see the part that you think will definitely not go wrong, it may be that you feel that your current technology is too superficial , want to go deeper , or may be influenced by the people around you , study together .

Buddhism pays attention to causality , users often touch the fruit , because the user cares about usability , the developer or the designer must consider the cause , because what kind of cause will lead to what kind of fruit , because of this design , So there is such a bug, like Neo in the Matrix, to find the architecture!

The origin of this article in mind two questions, i.e. how ordinary memory device is a block device into the partition, the root is how to mount.

Usually , after the processor is powered on , the earliest executed code is the program that is solidified in the CPU ROM. It is actually the earliest executed bootloader. Its ultimate purpose is to load another bootloader from the storage medium ( including uart, USB), for example. U-boot. Take the boot media is eMMC or SD example , romcode will generally start reading the program from the offset = sector_size * 1 position , the reason for this is actually to jump off the partition table .

Of course, I have seen a wonderful example of a Hass chip of ARM9, ROMCODE offset position 0 start reading directly from eMMC data partition, which led to when you start from the u-boot on emmc, excitedly After entering the ramdisk to partition the eMMC, format , and burn the system , I found that the system can no longer get up . That is because the partition table has covered the first partition and destroyed the bootloader. The entire system does not use the partitioning tool. the zoning, but the arguments describing partition information through boot u-boot in. in any case, this article describes the former, rather than the exception.

Storage devices under Linux are usually accessed as block devices , such as mtdblock, mmcblock, and the universe's strongest nandblk block device ( it is too adoring the device to bring NAND to the extreme ). The device driver of the storage device acts as the underlying support . and directly responsible for registering the block device and a memory device to deal with, receiving, over the access request execution and response of the block layer. For example, a file read operation becomes submitted to the file system block read request the block device, which The read access request of the block device is sent to the EMMC physical device by the CMD17 or CMD18 command that is converted to the MMC protocol in the block device driver and the Host controller driver.

The device driver of the storage device registers to the block device layer , scans the partition table , identifies the partition table , and then parses the partition table , registers the partition on the disk as a block device . So , when you wonder why there is no mmcblkp0 device , it is not Mmcblk0p0, but p0 is defined as mmcblk0. It represents the entire disk . Let's look at the initialization process of a block device driver from the code :

We know that the boot argument of u-boot will bring the device name of the root device to the kernel . For example, the root=/dev/mmcblk0p2 parameter is used to inform the kernel that the root directory is located . Is it really that simple ?

It turned out that there was a little bit of a bend in it :

Originally in the chaos of the world , the kernel has initialized a ramfs for its future , and created some necessary directories and device nodes in ramfs, such as /dev, /dev/console, /root.

Then, to mount mmcblk0p2, look for it according to the device file name / dev / mmcblk0p2 device variables, create a device node / dev / root in ramfs, this device file is pointing devices mmcblk0p2. Then the device under ramfs / dev / mmcblk0p2 mounted to the lower ramfs / root. ramfs switching the current path to the / root. Having thus completed the working device mounted mmcblk0p2, but this time it is not a root.

Then, the kernel to mount devtmpfs dev directory, then call sys_chroot ( ".") To change root to the current path, which is ramfs of / root.

Reflected on the code :

So after the system is up , cat /proc/mounts , we can see the following information :

You can see that there is a file system of type rootfs, which is mounted to "/".

This file system is defined in init/do_mount.c , which is an instance of ramfs .

This type of file system is registered in init_rootfs() .

From the output of the mount command , we can see that /dev/mmcblk0p2 is mounted in the "/", but the root here is not the original root .

Conclusion

This article does not analyze the details of the code too much . On the one hand, this article is not for code analysis . On the other hand, many friends on the network have also done code analysis of block devices . This article lists the context of the code for better. The result of the expression analysis . Block layer is a very complex subsystem , there are a lot of content about it , such as IO-schecduler, buffer cache, etc. , I believe that I can study this subsystem more and more deeply .