Linux-Grundlagen Yocto – Linux im Eigenbau

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Continental Automotive GmbH

Yocto hat sich auf dem Embedded-Markt weitgehend als Standardlösung etabliert, wenn es um die Distribution von Linux in Form von Board-Support-Packages (BSPs) geht. Doch was hat es damit genau auf sich und was gibt es zu beachten, wenn man Yocto für seine Embedded-Linux-Lösung einsetzen möchte? Eine kleine Übersicht.

Wer sich mit dem Einsatz von Embedded Linux auseinandersetzt, steht früher oder später vor der Frage, welche Distribution zum Einsatz kommt und wie diese erstellt werden kann. Grundsätzlich gibt es zwei Möglichkeiten: Entweder man greift auf eine bestehende Distribution zurück, oder man erstellt seine eigene. Letzteres erledigt ein entsprechendes Buildsystem.

Während die Vielfalt an Buildsystemen vor einigen Jahren noch sehr groß und die Auswahl außerordentlich schwierig war, haben sich glücklicherweise einige Standards durchgesetzt, allen voran Yocto. Nahezu alle großen Hardwarehersteller haben sich auf Yocto als Standard zur Weitergabe von Linux-BSPs geeinigt. Doch was ist Yocto überhaupt und was kann man damit tun?

Was ist Yocto?

Eine erste Antwort auf die Frage, was Yocto überhaupt ist, liefert die Projektseite: Yocto ist keine Linux-Distribution! Es ist eine Sammlung von Werkzeugen und Mechanismen zum Erstellen einer eigenen Linux Distribution. Und genau genommen muss man auch vom „Yocto Projekt“ sprechen, denn es werden Werkzeuge vieler Teilprojekte zu einem einheitlichen Werkzeugkasten zusammengefasst.

Wenn Sie Entwickler, die Yocto verwenden, nach Ihren Erfahrungen bei den ersten Gehversuchen fragen, werden Sie mit sehr großer Wahrscheinlichkeit von allen dieselbe Antwort bekommen: Die Lernkurve ist sehr steil! Aber keine Sorge, das hat weniger mit der Qualität von Yocto oder mit der verfügbaren Dokumentation zu tun, sondern vielmehr mit der Flexibilität und dem enormen Funktionsumfang. Eine grundsätzliche Empfehlung lautet daher: Planen Sie für den Einstieg in Yocto ausreichend Zeit ein!

Für den „Hands-On“-Einstieg bietet Yocto bereits eine Referenzdistribution mit dem Namen „poky“ an. Poky ist ein nützliches und sehr umfangreiches Beispiel, wie eine Distribution mit dem Yocto Projekt erstellt werden kann.

Allerdings ist „poky“ auch die Grundlage für ein sehr gängiges Missverständnis: Sehr häufig (oder besser gesagt fast immer) wird diese Referenzimplementierung auch im Produktiveinsatz verwendet, da dies mit wenig Anpassungsaufwand machbar ist. Aber denken Sie daran: Es handelt sich um ein Beispiel; nicht mehr und nicht weniger!

Layer, Rezepte und Pakete

Doch zunächst zurück zu Yocto und den grundlegenden Strukturen: Ein sehr zentrales Konzept sind die sogenannten Layer, auf denen Yocto’s Blick auf eine Distribution basiert. Ein erster Layer kann das Board Support Package sein, weitere Layer können zum Beispiel Tools, Middleware, Konfiguration oder die Applikation beinhalten. Eine Distribution setzt sich also aus verschiedenen Layern zusammen.

Jeder Layer besteht aus Rezepten, die in einem bestimmten Verhältnis zueinander stehen oder etwas gemeinsam haben. So besteht der BSP Layer üblicherweise aus Bootloader und Kernel; die Gemeinsamkeit der Rezepte ist hier also die Anpassung an die Hardware. Layer beinhalten nicht nur Nutzdaten, sondern auch Metadaten, wie Konfiguration, Source URL und Paketversion. Jedes Rezept dient der Erzeugung eines Pakets.

Layer dienen nicht nur der sauberen Strukturierung einer Distribution, Sie erleichtern auch den Austausch von Komponenten und die Integration von Software von dritten Entwicklern.

Bitbake

Das dem Yocto-Projekt zu Grunde liegende Buildsystem heißt bitbake. Bitbake stammt aus dem Open Embedded Projekt. Es handelt sich dabei um einen Task Scheduler und eine Execution Engine, der zunächst Rezepte parst und (unter Berücksichtigung der Abhängigkeiten) die einzelnen Komponenten übersetzt und schlussendlich zum Gesamtsystem zusammensetzt.

Der Übersetzungsprozess enthält auch das Erstellen der notwendigen Toolchain, um die Abhängigkeiten zum Hostsystem so gering wie möglich zu halten. Aus diesem Grund nimmt der erste Build eines Systems mit Yocto entsprechend Zeit in Anspruch.

Wenn’s mal wieder länger dauert…

Tatsächlich sind Buildzeiten und Speicherbedarf ein Punkt, der häufig von der Nutzung von Yocto abschreckt. Der schlechte Ruf von Yocto in dieser Richtung ist aber nur eingeschränkt zu rechtfertigen. Bedingt durch die Tatsache, dass auch alle Komponenten, die für den Buildprozess notwendig sind, mit erstellt werden, müssen für das initiale Generieren eines Systems entsprechend Ressourcen geplant werden. Das ist natürlich sehr von der tatsächlichen Umgebung abhängig, aber ein guter Richtwert sind 1-2 Stunden Buildzeit und ca. 50 GByte Storage.

Unabhängig von der Tatsache, dass Speicher und Rechenzeit immer günstiger werden, müssen wir uns vor Augen führen, dass dies kein Prozess ist, den ein einzelner Entwickler regelmäßig ausführen wird. Vielmehr ist das komplette Erstellen des Systems für Tests und für Releases relevant.

Für den Applikationsentwickler kann auf einfachem Wege ein komplettes SDK erstellt werden, mit dem einzelne Teile völlig unabhängig entwickelt, gedebuggt und getestet werden können. Und für diejenigen, die sich mit der Erstellung des Gesamtsystems beschäftigen, bietet Yocto ebenfalls Mechanismen an, um die Roundtripzeiten zum Testen einzelner Änderungen zu reduzieren. Mit dem sogenannten SSTATE-Cache kann die Buildzeit um bis zu 80% reduziert werden. Unveränderte Pakete werden so zum Beispiel nicht mehr neu übersetzt. Dieser Cache kann sowohl lokal vorhanden sein, als auch über einen Server einem größeren Team bereitgestellt werden.

Zur einfachen Integration eigener Anpassungen an Software-Komponenten kann devtool verwendet werden. Wie auch bitbake stammt devtool aus dem Open Embedded Projekt. Mit devtool lassen sich Änderungen an Einzelkomponenten (wie zum Beispiel das Patchen des Linuxkernels) „on the fly“ erstellen und sauber in den Buildprozess integrieren.

Wenn mal etwas schief geht

Während für die Fehlersuche in einzelnen Teilkomponenten die üblichen Werkzeuge zum Einsatz kommen (wie zum Beispiel der GNU Debugger oder die durch den Linux Kernel bereitgestellten Funktionalitäten), so werden für das Erstellen einer Linux Distribution natürlich noch weitere Tools benötigt, um zum Beispiel Probleme im Buildprozess zu analysieren oder die Herkunft einzelner Teilkomponenten des Buildprozesses nachvollziehen zu können.

Selbstverständlich enthält der Yocto-Werkzeugkasten auch die entsprechenden Methoden, um mit diesen Fehlerszenarien umgehen zu können.

Security und CVE-Scanning

Das Erstellen einer eigenen Linux Distribution ist kein Einmalaufwand! Aktive Wartung und Pflege sind unverzichtbar und liegen in der Verwantwortung desjenigen, der die Distribution erstellt; demjenigen, der das Yocto-Projekt für seine Lösung einsetzt.

Ein wesentlicher (wenn nicht sogar der zentrale) Bestandteil der Pflege ist der Umgang mit Sicherheitslücken. Die Integration von sicherheitsrelevanten Patches liegt zwar in der Verantwortung des Yocto Einsetzenden. Das Yocto-Projekt selbst stellt aber einige nützliche Methoden zur Verfügung, mit denen bekannte Lücken in integrierten Paketen erkannt werden können. So kann für einzelne Pakete oder auch die ganze Distribution geprüft werden, ob für die zum Einsatz kommenden Versionen CVEs bekannt sind.

Dies funktioniert prinzipiell so, dass eine aktuell gehaltene lokale Kopie der National Vulnerability Database erstellt wird. Während der Erstellung eines Paketes wird dann geprüft ob Paketname und Version sich auf einen aktuell bekannten CVE matchen lassen. Im Falle eines Matches wird der Nutzer darauf hingewiesen. Sofern bestimmte CVEs für einen Use-Case nicht relevant sind, kann für diese eine Whitelist erstellt werden.

Open-Source-Compliance

Neben den rein technischen Aspekten sind beim Einsatz von Open-Source Software auch verschiedene rechtliche Aspekte zu betrachten. Es wird zwar häufig übersehen, doch ergeben sich hieraus einige grundlegende Anforderungen an ein Buildsystem. Eine Übersicht der verwendeten Softwarepakete und der zugrundeliegenden Lizenzen ist zwingend erforderlich. Das Erstellen einer solchen Übersicht muss automatisiert im Buildprozess passieren. Weiterhin ist eine Anforderung aller Open-Source Lizenzen die Weiterverbreitung des Lizenztextes. Das Sammeln und aggregieren aller zugrundeliegender Open-Source Lizenzen ist ebenfalls eine Aufgabe, die vom Buildsystem erledigt werden muss. Das Yocto Projekt kann diese Anforderungen abdecken.

Darüberhinaus kann die Verwendung eines standardisierten Buildprozesses, wie Ihn Yocto bietet, die Erfüllung weiterer Lizenzpflichten vereinfachen. So schreibt die GPLv2 zum Beispiel vor, dass Skripte zur Kompilierung und zur Installation des Executables bereitgestellt werden müssen. Wer auf eine standardisierte Buildumgebung zurückgreift, kann zu diesem Zweck natürlich auch auf die frei verfügbare Dokumentation zurückgreifen und liefert die Buildanleitung in Form geeigneter Rezepte. Das kann den Aufwand wesentlich reduzieren. Übrigens: Dieser Aspekt war einer der wesentlichen Gründe, warum Yocto von den großen Hardwareherstellern als de-facto-Standard durchgesetzt wurde! Eine einheitliche Buildumgebung bedeutet auch eine einheitliche Lösung zur Erfüllung von Lizenzpflichten. Und das wiederum reduziert den Aufwand für alle Beteiligten in einer Lieferkette.

Alternative Linux-Buildsysteme

Der Verwendung einer selbst erstellten Distribution steht die Verwendung einer bestehenden Distribution gegenüber. Hier hat sich Debian über die letzten Jahre am Markt etabliert.

Interessant im Kontext von Yocto: Auch eine Kombination beider Ansätze ist möglich. So kann zum Beispiel Yocto als Buildumgebung verwendet werden, die Distribution setzt sich aber aus Sourcen des Debian Projektes zusammen (somit kann auf die Pflege des Debian Projektes zurückgegriffen werden). Wer sich für diesen Ansatz interessiert, der sei auf das Civil Infrastructure Platform Projekt der Linux Foundation verwiesen.

Fazit

Yocto ist eine mächtige und moderne Sammlung von Methoden und Werkzeugen, die das Erstellen und die Pflege einer auf seinen Anwendungsfall abgestimmten Linux-Distribution ermöglichen. Der Fakt, dass sich das Buildsystem als de-facto Standard am Markt etabliert hat, erleichtert den Austausch zwischen verschiedenen Projekten und kann dem Anwender auch bei der Erfüllung von Lizenzpflichten helfen.

Es darf allerdings nicht vergessen werden, dass Yocto lediglich die notwendigen Werkzeuge bietet! Die Umsetzung – und insbesondere die Pflege – liegt in der Verantwortung desjenigen, der Yocto für seine Linux-Lösung einsetzt.

Yocto bietet einen enormen Funktionsumfang und kann den Nutzer in vielerlei Hinsicht unterstützen. Die damit verbundene Komplexität bedingt eine steile Lernkurve und somit eine ausreichende Einarbeitungszeit der zuständigen Personen, die Yocto verwenden sollen. Beim Neueinstieg in Yocto ist also ausreichend Zeit einzuplanen. Die Erfahrung zeigt, dass ein Training der Mitarbeiter nahezu unerlässlich ist.

Unabhängig von der Verwendung von Yocto sei an dieser Stelle angemerkt, dass die Verwendung eines standardisierten Buildsystems immer empfehlenswert ist! (auch falls Sie sich gegen Yocto entscheiden) Selbst entwickelte Buildumgebungen zur Erstellung von Linux Systemen sind fehlerträchtig, praktisch nicht wartbar und machen auch die Handhabung von Lizenzpflichten unnötig schwer.

Compliance

Was Entwickler über den Umgang mit Open Source Software wissen sollten

Maßgeschneidertes Linux

Yocto: Das geht auch automatisch!

Open Source

Debian oder Yocto – welches Linux-Buildsystem ist besser?

Die Autoren:

*Emeric Andrasi ist langjähriger Linux User und seit 15 Jahren als Moderator in Communtiy Foren, Webmaster und Sysadmin aktiv. Er arbeitet seit 8 Jahren als Softwarearchitekt und Entwickler für die Continental Automotive GmbH. Dort betreut er unter anderem GNSS Features und ist zuständig für eine umfangreiche Buildinfrastruktur für eine Automotive Embedded Linux Plattform.

*Jan Altenbergbeschäftigt sich seit mehr als 15 Jahren beruflich mit Linux. Er betreute u.a. verschiedene Arbeiten für das EU-Projekt OCEAN, welches sich zum Ziel setzte, eine offene Steuerungsplattform auf Basis von Realtime Linux zu schaffen. Weiterhin trug er bei einem namhaften Maschinenhersteller die volle konzeptionelle Verantwortung für die Einführung von Linux in der neuen Steuerungsgeneration. Von 2007-2019 arbeitete er für die Linutronix GmbH und leitete dort zuletzt den technischen Vertrieb. Jan Altenberg ist regelmäßiger Sprecher auf verschiedenen Fachkonferenzen und wurde 2014, 2018 und 2019 von den Besuchern des ESE Kongress mit dem Speaker Award Publikumspreis ausgezeichnet. Seit April 2019 arbeitet er als System Architekt und Experte für Open-Source Technologien für die Continental Automotive GmbH.

(ID:46399080)