Por: McPro
Componentes del Proyecto Yocto y sus proyectos upstream.
La plataforma Linux embebida proporcionada por el Proyecto Yocto tiene la capacidad de generar un sistema integrado basado en Linux, adaptado a las características específicas de un proyecto determinado. El valor de Yocto para su distribución personalizada se dispara al personalizar el flujo de trabajo y utilizar las capacidades existentes para favorecer el cumplimiento de licencias.
El título de la página web del proyecto 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 consejo integrado y los requisitos del producto futuro puede ser difícil, pero el Proyecto Yocto está aquí para ayudar. 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 componen
tes fundamentales del Proyecto Yocto. Como se puede ver en la figura 1, 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, conocidos como “meta-yocto” y “meta-yocto-bsp”, incluyen integración con Eclipse y otras herramientas. Combinados, mejoran las herramientas del 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.
Comienzo de 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). 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 a continuación: las capas añaden soporte de hardware, de aplicaciones e incluso adaptaciones locales, y se pueden mezclar y combinar según sea necesario.
Uso de capas en el Proyecto Yocto/Poky.
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:
[start Box, Font Courier]# Crear una subcarpeta
> mkdir yocto ; cd yocto
# Descargar poky:
> wget -O poky.tar.bz2 -nd http://bit.ly/YCpoky
> 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
[stop Box, Font Courier]¿Cómo se escalaría todo eso entre grupos de trabajo?
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 to
do 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.
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 q
ue 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.
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.