The essential interpretation of Hongmeng OS open source code-init

The essential interpretation of Hongmeng OS open source code-init

Author introduction :

Zhongke Chuangda OpenHarmony Research Group

Description :

  The OpenHarmony research group of Zhongke Chuangda conducted detailed code study and study on the open source code on https://codechina.csdn.net/openharmony for the first time . To this end, we intend to write a series of medium-sized and refined source code analysis articles to lead everyone to further enter Hongmeng OS. With the understanding of the code, the willingness and confidence of the majority of developers to participate in it will also increase-this is also the meaning of Hongmeng OS open source.

Summary of this article :

This article takes ipcamera_hi3518ev300 in OpenHarmony as the compilation target and introduces the relevant code of the init process.

Words written in the front

We have performed a simple and rough statistics on the OpenHarmony code. Excluding all third_party code (that is, the third-party open source library used by OpenHarmony), among other remaining codes, use .c and .h files as the statistical entry, and the total number of effective code lines (excluding comments, blank lines, etc.) tSourceCounter) is 325627 lines. Among them, the total number of valid code lines in the attribution kernel directory is 74,150 lines. In the entire OpenHarmony, the kernel part accounts for about 22.8%, and the main part of the code is the part above the kernel, which we call the Framework. According to our many years of exploration and experience on the Android system, Framework is precisely the essence of Android OS. Therefore, based on OpenHarmony's current framework code volume of only more than 200,000 lines, there is a great opportunity for interested developers to participate in joint construction and contribute ideas in this area.

1. Download and compile OpenHarmony source code

First introduce the download and compilation of the code. Our research group used ubuntu 19.10 host environment.

1.1  source download

Follow the source code download guide on the codechina.csdn official website: https://codechina.csdn.net/openharmony/docs/-/blob/master/get-code/%E6%BA%90%E7%A0%81%E8%8E %B7%E5%8F%96.md

We use the fourth method "Acquisition Method 4: Obtain from Code Warehouse". Execute several commands in this section to get the entire source code repository.

1.2  Compile the source code

The compilation target we chose is "Hi3518 solution", and the compiled output directory is named ipcamera_hi3518ev300. ipcamera_hi3518ev300 is an ip camera device based on HiSilicon. The relevant introduction document entry is at https://codechina.csdn.net/openharmony/docs/-/blob/master/quick-start/%E6%90%AD%E5%BB%BA%E7%8E%AF%E5 %A2%83-2.md .

Note that the compilation of different solutions requires the establishment of a corresponding compilation environment. For hi3518, developers need to download and configure according to the "build environment" in the above link.

After everything is ready, execute python build.py in the source root directory. If there is no parameter, it will remind you to specify the compilation target. The screenshot is as follows:

Figure 1 The execution result of python build.py without parameters

This time, we can compile "Hi3518 Solution" through python build.py ipcamera_hi3518ev300. Compilation takes 10 minutes.

Note that there may be an error that <valgrind/valgrind.h> cannot be found during the compilation process. This is because the valgrind header file is not included in the code currently downloaded. Developers can manually copy the /usr/include/valgrind directory to prebuilts/lite/sysroot/usr/include (Only for Ubuntu platform, valgrind tool needs to be installed in advance).

1.3 Introduction to OpenHarmony Compilation Related Knowledge

The OpenHarmony source code compilation system uses the gn tool and ninjia developed by Google. The combination of the two is more efficient than the traditional makefile compilation system, and is especially suitable for parallel compilation of large systems. For developers, if you want to participate in the development of OpenHarmony, you need to understand the syntax of gn. This article only does some basic introduction:

1. Using the gn tool, the developer writes the compilation rules in a file named BUILD.gn. Like Makefile, gn file has its own grammatical rules and belongs to Domain Specific Language (DSL). The gn grammar is not difficult, but the compilation rules themselves have a lot of content, so it is not easy to master all of them at once.
2. gn supports custom template functions, which can be placed in a file named .gni. The most common gn template file in OpenHarmony is ./build/lite/config/component/lite_component.gni. Gni template files can be imported through import in .gn files. OpenHarmony defines template functions such as lite_component and lite_library.
3. In gn, the compilation function entry of the executable file is exectuable ("file name"), and the compilation rule function of the shared library is shared_library ("file name"). So, if you want to search for the compilation rules corresponding to a file, you can search all the BUILD.gn files first, and then grep executable. The following is a screenshot of all executable results of our grep.

Figure 2 shows the result of executable in grep BUILD.gn

In this way, we can quickly locate the code corresponding to init, for example.

Finally, we briefly introduce a conditional compilation control variable ohos_kernel_type related to the underlying OS in the OpenHarmony compilation system. Currently, this variable has four values, namely "liteos_a", "liteos_m", "liteos_riscv" and "linux":

1. "liteos_a" and "linux" are often judged as a group. liteos_a actually corresponds to the Cortex-A series, which has relatively high performance and can run on Linux systems.
2. "liteos_m" and "liteos_riscv" are often a group. liteos_m corresponds to the Cortex-M series, and liteos_riscv is the representation of the Riscv chip. Both may be for devices with average performance and lower power consumption.

The value of ohos_kernel_type is determined by the product field in the build/lite/product/solution name.json file. For example, the screenshot of the configuration file content of the ipcamera_hi3518ev300 we selected is as follows, and its kernel field value is "liteos_a".

Figure 3 Schematic diagram of the configuration file build/lite/product/ipcamera_hi3518ev300.json

 After the compilation is complete, all the compiled products are in the out/ipcamera_hi3518ev300 directory.

2 Essential analysis of init source code

init is the first application process on the Linux system and the source of other processes. For ipcamera_hi3518ev300, there is also an init process in its compiled product.

In the out/ipcamera_hi3518ev300 directory mentioned above, there is a rootfs.tar file. This file contains the contents of the root file system on the device. Open the /rootfs/bin directory, you can see the executable program compiled this time as shown in the screenshot below:

Figure 4 shows the content of out/ipcamera_hi3518ev300/rootfs.tar/bin

With the help of the method mentioned in Figure 2, we can locate the code path corresponding to init as base/startup/services/init_lite/. Its content is shown in the figure below:

Figure 5 Schematic diagram of init_lite source file

main.c is the entrance to the entire init. Let's take a brief look at its code, as shown below.

Figure 6 init_lite/main.c

The init main function is very concise, very consistent with the lightweight and simple style of "lite". Of course, it does not rule out that init code will become more and more complex in the future. The situation we observed on AOSP is an example-the current init code in AOSP is very complicated).

We are more interested in InitReadCfg, this function will read the /etc/init.cfg file internally. This file can be found in rootfs.tar mentioned in Figure 4. The following figure shows its contents:

Figure 7 rootfs.tar/etc/init.cfg

init.cfg is essentially a file in json format. It includes an array named "jobs" and an array named "services".

1. For "jobs": it contains three elements "pre-init", "init" and "post-init". As can be seen from the screenshot above, these three elements correspond to setting up and mounting some devices, setting up paths, and starting services.
2. For "services": it contains the definition of a set of services. The so-called service is the key process in the system. It can be guessed that init will start the corresponding service program according to the service configuration, and set its uid, gid, process priority and permissions, etc.

If developers have a certain understanding of the Android system, they will find that OpenHarmony and AOSP have similar design ideas in the init workflow. However, for the OpenHarmony target device, using the json format is undoubtedly relatively simple and convenient.

Finally, let's look at another important function of init-service process status monitoring. Those services in init.cfg belong to the critical process of the system. If they are abnormal and cause the process to exit during operation, there needs to be a way to restart them to ensure business continuity.

The realization of this function is to use the SIGCHILD signal of the Linux system. Init monitors the signal in SignalInitModule and sets the corresponding signal processing function-SigHandler. The specific processing of the SigHandler function is a bit more complicated than what is said here. Now, this part of the content is left for readers to explore on their own! !