La interpretación esencial del código fuente abierto del sistema operativo Hongmeng-init

Introducción del autor :

Grupo de Investigación OpenHarmony de Zhongke Chuangda

Descripción :

El grupo de investigación OpenHarmony de Zhongke Chuangda realizó un estudio de código detallado y un estudio sobre el código fuente abierto en https://codechina.csdn.net/openharmony por primera vez . Con este fin, tenemos la intención de escribir una serie de artículos de análisis de código fuente refinados y de tamaño mediano para llevar a todos a ingresar aún más al sistema operativo Hongmeng. Con la comprensión del código, también aumentará la voluntad y la confianza de la mayoría de los desarrolladores para participar en él; este es también el significado del código abierto del sistema operativo Hongmeng.

Resumen de este artículo :

Este artículo toma ipcamera_hi3518ev300 en OpenHarmony como el destino de compilación e introduce el código relevante del proceso de inicio.

Palabras escritas en el frente

Hemos realizado una estadística simple y aproximada sobre el código OpenHarmony. Excluyendo todo el código de terceros (es decir, la biblioteca de código abierto de terceros utilizada por OpenHarmony), entre otros códigos restantes, utilice los archivos .cy .h como entrada estadística y el número total de líneas de código efectivas (sin incluir comentarios, líneas en blanco, etc.). La herramienta estadística es tSourceCounter) es 325627 líneas. Entre ellos, el número total de líneas de código válidas en el directorio del kernel de atribución es de 74.150 líneas. En todo OpenHarmony, la parte del kernel representa aproximadamente el 22,8%, y la parte principal del código es la parte superior al kernel, que llamamos Framework. Según nuestros muchos años de exploración y experiencia en el sistema Android, Framework es precisamente la esencia del sistema operativo Android. Por lo tanto, basado en el volumen de código marco actual de OpenHarmony de solo más de 200,000 líneas, existe una gran oportunidad para que los desarrolladores interesados participen en la construcción conjunta y contribuyan ideas en esta área.

1. Descargue y compile el código fuente de OpenHarmony

Primero introduzca la descarga y compilación del código. Nuestro grupo de investigación utilizó el entorno de host ubuntu 19.10.

1.1 descarga de la fuente

Siga la guía de descarga del código fuente en el sitio web oficial codechina.csdn: https://codechina.csdn.net/openharmony/docs/-/blob/master/get-code/%E6%BA%90%E7%A0%81%E8%8E % B7% E5% 8F% 96.md

Usamos el cuarto método "Método de adquisición 4: Obtener de Code Warehouse". Ejecute varios comandos en esta sección para obtener el repositorio de código fuente completo.

1.2 Compilar el código fuente

El objetivo de compilación que elegimos es "Solución Hi3518", y el directorio de salida compilado se llama ipcamera_hi3518ev300. ipcamera_hi3518ev300 es un dispositivo de cámara IP basado en HiSilicon. La entrada del documento de introducción relevante se encuentra en https://codechina.csdn.net/openharmony/docs/-/blob/master/quick-start/%E6%90%AD%E5%BB%BA%E7%8E%AF%E5 % A2% 83-2.md .

Tenga en cuenta que la compilación de diferentes soluciones requiere el establecimiento de un entorno de compilación correspondiente. Para hi3518, los desarrolladores deben descargar y configurar de acuerdo con el "entorno de compilación" en el enlace anterior.

Una vez que todo esté listo, ejecute python build.py en el directorio raíz de origen. Si no hay ningún parámetro, le recordará que especifique el destino de compilación. La captura de pantalla es la siguiente:

Figura 1 El resultado de la ejecución de python build.py sin parámetros

Esta vez, podemos compilar la "Solución Hi3518" a través de python build.py ipcamera_hi3518ev300. La compilación tarda 10 minutos.

Tenga en cuenta que puede haber un error que indique que <valgrind / valgrind.h> no se puede encontrar durante el proceso de compilación. Esto se debe a que el archivo de encabezado valgrind no está incluido en el código descargado actualmente. Los desarrolladores pueden copiar manualmente el directorio / usr / include / valgrind en prebuilts / lite / sysroot / usr / include (solo para la plataforma Ubuntu, la herramienta valgrind debe instalarse con anticipación).

1.3 Introducción al conocimiento relacionado con la compilación OpenHarmony

El sistema de compilación de código fuente OpenHarmony utiliza la herramienta gn y ninjia desarrollada por Google. La combinación de los dos es más eficiente que el sistema de compilación tradicional de archivos MAKE y es especialmente adecuada para la compilación en paralelo de sistemas grandes. Para los desarrolladores, si desean participar en el desarrollo de OpenHarmony, deben comprender la sintaxis de gn. Este artículo solo hace una introducción básica:

Usando la herramienta gn, el desarrollador escribe las reglas de compilación en un archivo llamado BUILD.gn. Al igual que Makefile, el archivo gn tiene sus propias reglas gramaticales y pertenece al lenguaje específico del dominio (DSL). La gramática gn no es difícil, pero las propias reglas de compilación tienen mucho contenido, por lo que no es fácil dominarlas todas a la vez.
gn admite funciones de plantilla personalizadas, que se pueden colocar en un archivo llamado .gni. El archivo de plantilla gn más común en OpenHarmony es ./build/lite/config/component/lite_component.gni. Los archivos de plantilla de GNI se pueden importar mediante la importación en archivos .gn. OpenHarmony define funciones de plantilla como lite_component y lite_library.
En gn, la entrada de la función de compilación del archivo ejecutable es ejecutable ("nombre de archivo"), y la función de regla de compilación de la biblioteca compartida es shared_library ("nombre de archivo"). Por lo tanto, si desea buscar las reglas de compilación correspondientes a un archivo, puede buscar primero todos los archivos BUILD.gn y luego el ejecutable grep. La siguiente es una captura de pantalla de todos los resultados ejecutables de nuestro grep.

La Figura 2 muestra el resultado del ejecutable en grep BUILD.gn

De esta forma, podemos localizar rápidamente el código correspondiente a init, por ejemplo.

Finalmente, presentamos brevemente una variable de control de compilación condicional ohos_kernel_type relacionada con el sistema operativo subyacente en el sistema de compilación OpenHarmony. Actualmente, esta variable tiene cuatro valores, a saber, "liteos_a", "liteos_m", "liteos_riscv" y "linux":

"liteos_a" y "linux" a menudo se juzgan como un grupo. liteos_a en realidad corresponde a la serie Cortex-A, que tiene un rendimiento relativamente alto y puede ejecutarse en sistemas Linux.
"liteos_m" y "liteos_riscv" suelen ser un grupo. liteos_m corresponde a la serie Cortex-M, y liteos_riscv es la representación del chip Riscv, ambos pueden ser para dispositivos con rendimiento medio y menor consumo de energía.

El valor de ohos_kernel_type está determinado por el campo del producto en el archivo build / lite / product / solution name.json. Por ejemplo, la captura de pantalla del contenido del archivo de configuración de la cámara ipcamera_hi3518ev300 que seleccionamos es la siguiente, y su valor de campo del kernel es "liteos_a".

Figura 3 Diagrama esquemático del archivo de configuración build / lite / product / ipcamera_hi3518ev300.json

Una vez completada la compilación, todos los productos compilados se encuentran en el directorio out / ipcamera_hi3518ev300.

2 Análisis esencial del código fuente init

init es el primer proceso de aplicación en el sistema Linux y la fuente de otros procesos. Para ipcamera_hi3518ev300, también hay un proceso de inicio en su producto compilado.

En el directorio out / ipcamera_hi3518ev300 mencionado anteriormente, hay un archivo rootfs.tar. Este archivo contiene el contenido del sistema de archivos raíz del dispositivo. Abra el directorio / rootfs / bin, puede ver el programa ejecutable compilado esta vez como se muestra en la captura de pantalla a continuación:

La figura 4 muestra el contenido de out / ipcamera_hi3518ev300 / rootfs.tar / bin

Con la ayuda del método mencionado en la Figura 2, podemos ubicar la ruta del código correspondiente a init como base / startup / services / init_lite /. Su contenido se muestra en la siguiente figura:

Figura 5 Diagrama esquemático del archivo fuente init_lite

main.c es la entrada a todo init. Echemos un vistazo breve a su código, como se muestra a continuación.

Figura 6 init_lite / main.c

La función principal de init es muy concisa, muy consistente con el estilo simple y ligero de "lite". Eso sí, no descarta que el código de inicio se vuelva cada vez más complicado en el futuro. La situación que observamos en AOSP es un ejemplo: el código de inicio actual en AOSP es muy complicado).

Estamos más interesados en InitReadCfg, esta función leerá el archivo /etc/init.cfg internamente. Este archivo se puede encontrar en rootfs.tar mencionado en la Figura 4. La siguiente figura muestra su contenido:

Figura 7 rootfs.tar / etc / init.cfg

init.cfg es esencialmente un archivo en formato json. Incluye una matriz denominada "trabajos" y una matriz denominada "servicios".

Para "trabajos": contiene tres elementos "pre-init", "init" y "post-init". Como se puede ver en la captura de pantalla anterior, estos tres elementos corresponden a configurar y montar algunos dispositivos, configurar rutas e iniciar servicios.
Para "servicios": contiene la definición de un conjunto de servicios. El llamado servicio es el proceso clave en el sistema. Se puede adivinar que init iniciará el programa de servicio correspondiente de acuerdo con la configuración del servicio y establecerá su uid, gid, prioridad de proceso y permisos, etc.

Si los desarrolladores tienen cierto conocimiento del sistema Android, encontrarán que OpenHarmony y AOSP tienen ideas de diseño similares en el flujo de trabajo de inicio. Sin embargo, para el dispositivo de destino OpenHarmony, usar el formato json es, sin duda, relativamente simple y conveniente.

Finalmente, veamos otra función importante del monitoreo del estado del proceso del servicio init. Estos servicios en init.cfg pertenecen al proceso crítico del sistema. Si son anormales y hacen que el proceso se cierre durante la operación, debe haber una forma de reiniciarlos para garantizar la continuidad del negocio.

La realización de esta función es utilizar la señal SIGCHILD del sistema Linux. Init monitorea la señal en SignalInitModule y establece la función de procesamiento de señal correspondiente: SigHandler. El procesamiento específico de la función SigHandler es un poco más complicado de lo que se dice aquí. Ahora, esta parte del contenido se deja para que los lectores la exploren por su cuenta. !