Inicio Artículos de fondo Proyecto Yocto: Linux embebido personalizado

Proyecto Yocto: Linux embebido personalizado

980
0
Componentes del Proyecto Yocto
Componentes del Proyecto Yocto y sus proyectos upstream

El título de la página web del Proyecto Yocto reza: «No es una distribución de Linux embebido, sino que crea una personalizada para usted». Realmente describe su misión: crear un sistema operativo personalizado basado en Linux, adaptado a las características específicas de un producto integrado y a los requisitos del producto futuro, lo que puede ser un poco difícil, pero el Proyecto Yocto está aquí para ayudar.

El Proyecto Yocto, por ser un proyecto colaborativo de código abierto, gestionado por la Fundación Linux, soporta múltiples arquitecturas, incluyendo x86 (32/64 bits), PPC, ARM y MIPS. Es compatible con un número cada vez mayor de placas gracias a las capas de soporte de placas.

Para empezar, vamos a echar un breve vistazo a los componentes fundamentales del Proyecto Yocto. Como se puede ver en la figura 1, el Proyecto Yocto es una colección de múltiples componentes. Integra partes desarrolladas conjuntamente con su proyecto hermano OpenEmbedded, incluyendo BitBake, OpenEmbedded-Core y otros metadatos. Los componentes desarrollados en el marco del Proyecto Yocto, conocidos como «meta-yocto» y «meta-yocto-bsp», incluyen integración con Eclipse y otras herramientas. Combinados, mejoran las herramientas del proyecto OpenEmbedded con los componentes Yocto y conforman la plataforma de referencia Poky. Se podría decir que Poky es un marco mejorado para desarrollar sistemas basados ​​en Linux. Hay que pensar en ello como «un Buildroot con esteroides».

Para desarrollar software, necesitamos una cadena de herramientas (cruzada): los archivos fuente e instrucciones sobre cómo compilarlos. Eso es suficiente para una sola fuente. Pero con más componentes y dependencias en tiempo de compilación y ejecución, se incrementa la complejidad y se necesitan pasos adicionales. Estos pasos conforman una receta para desarrollar el software en cuestión. Se podrían establecer variantes en base a políticas como la arquitectura objetivo o el hardware de destino. Se podría concluir que OpenEmbedded-Core es una colección de recetas de ese tipo, aunque en realidad es el conjunto fundacional de recetas. meta-yocto y meta-yocto-bsp también son colecciones de recetas y mejoran los metadatos de OE-Core. Bitbake es ahora el intérprete y ejecutor de las recetas mencionadas, calcula la cadena de tareas que se necesitan para desarrollar el objetivo definido, y lo ejecuta.

Trabajando con el proyecto Yocto

Para comenzar con Yocto, el usuario solo tiene que crear un nuevo entorno de proyecto y editar el archivo «conf/local.conf» para elegir la placa de destino a través de la variable «MACHINE» antes de simplemente ejecutar «bitbake» seguido de un destino como ”bitbake core-image-minimal“. Pero la verdadera fuerza del Proyecto Yocto radica en su flexibilidad para añadir nuevas recetas, modificar las existentes o cambiar políticas mediante la adición de metadatos en una capa así llamada en la parte superior de la pila de capas existente (OE-Core + meta-yocto + meta-yocto-bsp).

Uso de capas en el Proyecto Yocto/Poky
Uso de capas en el Proyecto Yocto/Poky

Un ejemplo de cómo extender un archivo de receta, que se nombra por convención con la extensión «.bb» (por ejemplo, «hola.bb») es tan sencillo como añadir un archivo con el mismo nombre y la extensión «.bbappend» (por ejemplo, «hola.bbappend»). Esto reduce drásticamente el trabajo de mantenimiento, puesto que los integradores de sistemas solo tienen que realizar un seguimiento de la pequeña modificación al archivo .bbappend en lugar de una copia completa. Entonces, las actualizaciones de mantenimiento de los proyectos upstream se heredan reconstruyendo la imagen sin necesidad de editar ni un solo archivo de metadatos. Esto es una clara ventaja que justifica los ciclos cerebrales adicionales que se necesitan para crear un pequeño archivo «.bbappend» en lugar de editar copias de las recetas originales.

Las recetas se guardan en capas dentro de subcarpetas para cada tema funcional. Se pueden utilizar múltiples capas al mismo tiempo. Se muestra este concepto en la figura 2, las capas añaden soporte de hardware, de aplicaciones e incluso adaptaciones locales, y se pueden mezclar y combinar según sea necesario.

Para probar «poky», la plataforma de referencia del Proyecto Yocto, solo se necesita una máquina que ejecute Linux, 80 GB de espacio libre en disco duro, y seguir esta breve guía de 5 pasos:

# Crear una subcarpeta
> mkdir yocto ; cd yocto

# Descargar poky:
> wget -O poky.tar.bz2 -nd 
> tar -xf poky.tar.bz2

# Crear nuevo entorno de proyecto
> source poky-dizzy-12.0.0/oe-init-build-env myproj
# El valor predeterminado es qemux86
# como se puede ver en
# conf/local.conf
# Solo vamos a compilar;
# se necesita red, gran cantidad de disco
# y tiempo (de cpu)
> bitbake core-image-minimal
# La salida está en
# tmp/deploy/images
# Se prueba con
> runqemu

Como se verá, la compilación inicial toma bastante tiempo, ya que tiene que recuperar las fuentes y compilarlo todo, incluyendo el compilador cruzado/la cadena de herramientas. Una pregunta razonable es: ¿cómo se escalaría todo eso entre grupos de trabajo, o si funcionaría tras firewalls corporativos? Yocto tiene respuestas a estas preguntas. Una característica es el uso de una carpeta de descarga (DL_DIR en local.conf) a modo de caché para las descargas, y es el primer lugar donde bitbake buscará fuentes. Esto posibilita tener una carpeta de descarga compartida. Por otro lado, la función PREMIRRORS nos permite dirigir pérdidas de caché de descarga a un mirror propio.

El otro problema con respecto al escalado es el tiempo de compilación real. Seguro que tendrá presente cuánto tiempo se tarda en descargar y desarrollar todas partes y componentes de core-image-minimal. Ahora, haga sus cálculos para un grupo de trabajo de 10 equipos. ¡Vaya! Menuda pérdida de tiempo de CPU. Yocto puede hacerlo mejor, y nos ofrece la SSTATE_CACHE. Se trata de una caché de resultados de compilación por entorno de destino (combinación de máquina+compilador). Podemos orientar las futuras carpetas de proyectos a una carpeta SSTATE_CACHE existente y bitbake recogerá los binarios existentes, acelerando la compilación drásticamente. También hay SSTATE_MIRRORS, que podrían consistir en una dirección URL en la red local (p. ej., alimentados por un autocompilador o mediante integración continua). De este modo, se proporcionarían binarios recientes a todos los miembros del grupo de trabajo.

Como podrá imaginar, esto es solo la punta del iceberg en términos de la posible personalización dentro del Proyecto Yocto.

Otra parte importante es saber acerca de las licencias para el software utilizado en el sistema de archivos, o incluso excluir software con ciertas licencias. En primer lugar, todo el software desarrollado con Yocto tiene que informar de su licencia en la receta. Cada paquete desarrollado con Yocto tiene una subcarpeta en el directorio

<myproj/tmp/deploy/licenses/>. Esto significa que podemos controlar y verificar qué licencias se utilizan en el sistema de archivos de destino. Además, podemos introducir las licencias en listas negras o blancas, lo que nos permitiría excluir o incluir software liberado bajo tales licencias. La lista negra se hace con INCOMPATIBLE_LICENSE y la lista blanca es posible gracias a LICENSE_FLAGS o LICENSE_FLAGS_WHITELIST.

Cómo utilizar el proyecto Yocto

Vamos a completar esta introducción con algunos consejos sobre las mejores prácticas. Una importante lección que aprender es la de usar integración continua desde el principio mismo. No solo reduce su tiempo de salida al mercado y el tiempo de vida del software lanzado en el producto, sino que también simplifica las actualizaciones y mejoras a posteriori. Esto se automatizar, por ejemplo, con una configuración de gerrit y jenkins. Llevar la batuta del desarrollo le permite trabajar directamente con los desarrolladores upstream del Proyecto Yocto, e influir en el desarrollo mediante la presentación de parches para simplificar el siguiente ciclo de versión y actualización.

Para concluir, acerca de las actualizaciones: En un mundo conectado y con la Internet de las cosas justo frente a nosotros, tenemos que procurar actualizaciones oportunas y frecuentes. Ello implica dos cosas: a) hay que ser capaz de adaptarse e importar estas correcciones (¡¿recuerda la integración continua?!), y b) los dispositivos tienen que recuperar y aplicar las actualizaciones. El Proyecto Yocto se puede configurar para paquetes de salida y package-feeds de varios formatos y tamaños (rpm, dpkg, opkg) para conseguirlo.

En caso de que usted esté pensando ahora mismo: «me gustaría saber más…»: el curso LFD405 de Linux Foundation (2 de marzo de 2015 en Stuttgart, vea training.linuxfoundation.org) podría venirle de perlas, así como el evento Developer Days del Proyecto Yocto.