Weiter: A. Anhang zum Paket Hoch: 1. Dokumentation des Paketes Zurück: 1. Dokumentation des Paketes
Dieses Kapitel ist hauptsächlich für Entwickler interessant, die Binärprogramme oder Linux-Kernel für den fli4l übersetzen wollen. Wenn Sie fli4l nur als Router einsetzen und keine Pakete für den fli4l anbieten wollen, die eigene Binärprogramme benötigen, können Sie dieses Kapitel komplett überspringen.
Generell ist für die Übersetzung von Programmpaketen für den fli4l ein Linux-System erforderlich. Eine Übersetzung unter anderen Betriebssystemen (Microsoft Windows, OS X, FreeBSD etc.) wird nicht unterstützt.
Die Anforderungen an ein Linux-System zur fli4l-Entwicklung sind wie folgt:
Im Folgenden repräsentieren fett gedruckte Zeichen zu tätigende
Eingaben, das 
-Zeichen steht für die Eingabetaste Ihrer Tastatur und
schließt einzugebende Befehle ab.
Im src-Verzeichnis finden Sie folgende Unterverzeichnisse:
| Verzeichnis | Inhalt |
| fbr | In diesem Verzeichnis befindet sich ein angepasstes Buildsystem, das auf dem Buildroot zur uClibc (aktuell in der Version 0.9.33.2) basiert. FBR steht hierbei für ``fli4l-Buildroot''. Damit ist es möglich, alle auf dem fli4l verwendeten Programme (Kernel, Anwendungen und Bibliotheken) neu zu übersetzen. |
| fli4l | Dieses Verzeichnis enthält die fli4l-spezifischen Quellen, nach Paketen geordnet. Alle Quellen, die in diesem Unterverzeichnis enthalten sind, wurden entweder speziell für die Verwendung mit fli4l geschrieben oder zumindest stark angepasst. |
| cross | In diesem Verzeichnis befinden sich Skripte, mit denen die Cross-Compiler erstellt werden können, die für das Übersetzen von mkfli4l für diverse Plattformen benötigt werden. |
Im Unterverzeichnis ``fbr'' finden Sie das Skript fbr-make, das die Übersetzung aller Programme aus den Basispaketen für den fli4l-Router steuert. Dieses Skript kümmert sich um das Herunterladen und Übersetzen aller für den fli4l benötigten Binärdateien. Generell legt das Skript Dateien in dem Verzeichnis ˜/.fbr ab; existiert dieses noch nicht, wird es angelegt. (Dieses Verzeichnis kann mit Hilfe der Umgebungsvariable FBR_BASEDIR verändert werden, siehe unten.)
Hinweis: Während des Übersetzungsvorgangs wird viel Platz benötigt (momentan etwa 900 MiB für die heruntergeladenen Archive und knapp 30 GiB für die Zwischenergebnisse und die resultierenden Kompilate). Stellen Sie somit sicher, dass Sie unterhalb von ˜/.fbr über genug Platz verfügen! (Alternativ können Sie auch die FBR_TIDY-Option nutzen, siehe unten.)
Die Verzeichnisstruktur unterhalb von ˜/.fbr ist wie folgt:
| Verzeichnis | Inhalt |
| fbr-<branch>-<arch> | Hierhin wird das uClibc-Buildroot entpackt. <branch> steht hierbei für den Entwicklungszweig (z.B. trunk), aus dem das FBR stammt. Ist der Ursprung des FBRs ein entpacktes src-Paket, wird fbr-custom benutzt. <arch> steht für die jeweilige Prozessorarchitektur (z.B. x86 oder x86_64). Mehr zu diesem Verzeichnis steht weiter unten. |
| dl | Hier werden die heruntergeladenen Archive gespeichert. |
| own | Hier können eigene FBR-Pakete abgelegt werden, die ebenfalls übersetzt werden sollen. |
Unterhalb des Buildroot-Verzeichnisses ˜/.fbr/fbr-<branch>-<arch>/buildroot sind die folgenden Verzeichnisse interessant:
| Verzeichnis | Inhalt |
| output/sandbox | In diesem Verzeichnis gibt es für jedes FBR-Paket ein Unterverzeichnis, das die Dateien des FBR-Pakets nach dem Übersetzungsvorgang aufnimmt. In dem Verzeichnis output/sandbox/<paket>/target befinden sich dabei die Dateien, die für den fli4l-Router vorgesehen sind. In dem Verzeichnis output/sandbox/<paket>/staging hingegen befinden sich Dateien, die zum Übersetzen anderer FBR-Pakete, die dieses FBR-Paket benötigen, erforderlich sind. |
| output/target | In diesem Verzeichnis werden alle übersetzen Programme für den fli4l-Router abgelegt. Dieses Verzeichnis spiegelt somit die Verzeichnisstruktur auf dem fli4l-Router wider. Mit Hilfe von chroot kann man in dieses Verzeichnis wechseln und die übersetzten Programme ausprobieren.1.1 |
Die Arbeitsweise von fbr-make kann durch verschiedene Umgebungsvariablen beeinflusst werden:
| Variable | Beschreibung |
| FBR | Gibt den Pfad zum FBR explizit an. Standardmäßig wird der Pfad ˜/.fbr/fbr-<branch>-<arch> (s.o.) verwendet. |
| FBR_BASEDIR | Gibt den Basispfad zum FBR explizit an. Standardmäßig wird der Pfad ˜/.fbr (s.o.) verwendet. Diese Variable wird ignoriert, falls die Umgebungsvariable FBR gesetzt wird. |
| FBR_DLDIR | Gibt das Verzeichnis an, das die Quellarchive enthält. Standardmäßig wird der Pfad ${FBR}/../dl (also z.B. ˜/.fbr/dl) verwendet. |
| FBR_BRANCH | Gibt explizit den Namen des Branches an, unter dem die Pakete unterhalb von ˜/.fbr (s.o.)gebaut werden. Diese Variable wird ignoriert, falls die Umgebungsvariable FBR gesetzt wird. |
| FBR_CATEGORY | Gibt explizit den Namen der Category an, unter dem die Pakete unterhalb von ˜/.fbr (s.o.)gebaut werden. Diese Variable wird ignoriert, falls die Umgebungsvariable FBR gesetzt wird. |
| FBR_OWNDIR | Gibt das Verzeichnis an, das die eigenen Pakete enthält. Standardmäßig wird der Pfad ${FBR}/../own (also z.B. ˜/.fbr/own) verwendet. |
| FBR_TIDY | Wenn diese Variable den Wert ``y'' enthält, werden Zwischenergebnisse, die während des Bauens der FBR-Pakete entstehen, unmittelbar nach der Installation in das Verzeichnis output/target gelöscht. Das spart viel Speicherplatz und ist eigentlich immer empfehlenswert, wenn man nach dem Bauen von Paketen nicht den Drang verspürt, in output/build/... hineinzuschauen. Falls diese Variable den Wert ``k'' enthält, werden nur die Zwischenergebnisse in den diversen Linux-Kernel-Verzeichnissen entfernt, weil dies verhältnismäßig viel Platz spart, ohne dass dadurch Funktionalität verloren geht. Alle anderen Belegungen (oder wenn die Variable gänzlich fehlt) sorgen dafür, dass alle Zwischenergebnisse erhalten bleiben. |
| FBR_ARCH | Diese Variable gibt die Prozessorarchitektur an, für die das FBR (bzw. einzelne FBR-Pakete) gebaut werden sollen. Fehlt sie, wird x86 angenommen. Die unterstützten Architekturen sind weiter unten zu finden. |
Momentan unterstützt das FBR die folgenden Architekturen:
| Architektur | Beschreibung |
| x86 | Intel x86-Architektur (32-Bit), auch IA-32 genannt. |
| x86_64 | AMD x86-64-Architektur (64-Bit), von Intel auch Intel 64 oder EM64T genannt. |
Wenn Sie fbr-make mit dem Argument world ausführen, dauert es je nach verwendetem Rechner und verwendeter Internetanbindung mehrere Stunden, bis alle Quellarchive heruntergeladen und übersetzt worden sind.1.2
Wenn Sie fbr-make mit dem Argument toolchain ausführen, werden alle FBR-Pakete heruntergeladen und übersetzt, die für das Bauen der eigentlichen fli4l-Binärprogramme benötigt werden (also Übersetzer, Binder, uClibc-Bibliothek etc.). Normalerweise wird dieses Kommando nicht benötigt, da alle FBR-Pakete vom Toolchain abhängig sind und somit diese Toolchain-Programme ohnehin heruntergeladen und gebaut werden.
Wollen Sie hingegen nur ein bestimmtes FBR-Paket übersetzen (etwa die Programme für ein selbst entwickeltes OPT), können Sie den Namen des FBR-Pakets bzw. die Namen mehrerer FBR-Pakete dem fbr-make-Programm mitgeben (etwa fbr-make openvpn zum Herunterladen und Übersetzen der OpenVPN-Programme). Dabei werden alle nötigen Abhängigkeiten ebenfalls heruntergeladen und übersetzt.
Möchten Sie ein bestimmtes FBR-Paket erneut übersetzen (warum auch immer), müssen Sie zuerst die Informationen im FBR über den vorher stattgefundenen Übersetzungsvorgang entfernen. Dazu können Sie den Befehl fbr-make <paket>-clean (z.B. fbr-make openvpn-clean) verwenden. Dabei werden die Informationen all jener FBR-Pakete, die von dem angegebenen FBR-Paket abhängig sind, ebenfalls zurückgesetzt, so dass sie beim nächsten fbr-make world ebenfalls neu übersetzt werden.
Möchten Sie das komplette FBR neu übersetzen (z.B. weil Sie es als Benchmark-Programm für Ihr neues High-End-Entwicklersystem nutzen wollen ;-), können Sie mit Hilfe des Kommandos fbr-make clean nach der Bestätigung einer Sicherheitsabfrage alle Artefakte entfernen, die während des letzten FBR-Baus erzeugt worden sind.1.3 Dies ist auch nützlich, um belegten Plattenspeicher freizugeben.
Ist ein Programm mit fbr-make übersetzt worden, kann es auf dem Entwicklungsrechner auch getestet werden. Ein solcher Test funktioniert natürlich nur, wenn die Prozessorarchitektur des Entwicklerrechners mit der Prozessorarchitektur des fli4ls, für welchen die Programme übersetzt werden sollen, übereinstimmt. (Es ist z.B. nicht möglich, x86_64-fli4l-Programme auf einem x86-Betriebssystem auszuführen.) Ist diese Voraussetzung erfüllt, kann man mit
[commandchars=\\\{\}]
\textbf{chroot ~/.fbr/fbr-<branch>-<arch>/buildroot/output/target /bin/sh}\enter
in das fli4l-Zielverzeichnis wechseln und dort das/die übersetzte(n) Programm(e) direkt ausprobieren. Beachten Sie jedoch bitte, dass Sie für chroot Administrator-Rechte benötigen und daher je nach Vorliebe und Systemkonfiguration die Dienste von sudo oder su in Anspruch nehmen müssen! Auch müssen Sie zumindest das FBR-Paket busybox übersetzt haben (via fbr-make busybox), damit Sie in der chroot-Umgebung eine Shell zur Verfügung haben. Ein kleines Beispiel:
[commandchars=\\\{\}]
$ \textbf{sudo chroot ~/.fbr/fbr-trunk-x86/buildroot/output/target /bin/sh}\enter
Passwort:\textbf{(Ihr Passwort)}\enter
BusyBox v1.22.1 (fli4l) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# \textbf{ls}\enter
THIS_IS_NOT_YOUR_ROOT_FILESYSTEM mnt
bin opt
dev proc
etc root
home run
img sbin
include share
lib sys
lib32 tmp
libexec usr
man var
media windows
# \textbf{bc --version}\enter
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
# \textbf{echo "42 - 23" | bc}\enter
19
#
Macht ein Programm auf dem fli4l Probleme, mit anderen Worten: es stürzt ab, dann hat man die Möglichkeit, den Programmzustand unmittelbar vor dem Absturz nachträglich zu analysieren (auch ``Post-Mortem Debugging'' genannt). Hierzu muss man zuerst in der Konfiguration des base-Pakets DEBUG_ENABLE_CORE='yes' aktivieren. Wird dann beim Absturz ein Speicherabbild in /var/log/dumps/core.<PID> generiert, wobei ``PID'' die Prozessnummer des abgestürzten Prozesses ist, dann kann man den Zustand des Programms auf einem Linux-Rechner mit einem voll übersetzten FBR folgendermaßen analysieren. Im folgenden Beispiel ist das zu analysierende Programm /usr/sbin/collectd, das sich mit einem SIGBUS verabschiedet hatte. Das Speicherabbild liegt dabei in /tmp/core.collectd.
[commandchars=\\\%!]
fli4l@eisler:~$ \textbf%.fbr/fbr-trunk-x86/buildroot/output/host/usr/bin/i586-linux-gdb!\enter
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=i586-buildr
oot-linux-uclibc".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) \textbf%set sysroot /project/fli4l/.fbr/fbr-trunk-x86/buildroot/output/target!\enter
(gdb) \textbf%set debug-file-directory /project/fli4l/.fbr/fbr-trunk-x86/buildroot/outpu!
\textbf%t/debug!\enter
(gdb) \textbf%file /project/fli4l/.fbr/fbr-trunk-x86/buildroot/output/target/usr/sbin/co!
\textbf%llectd!\enter
Reading symbols from /project/fli4l/.fbr/fbr-trunk-x86/buildroot/output/target/u
sr/sbin/collectd...Reading symbols from /project/fli4l/.fbr/fbr-trunk-x86/buildr
oot/output/debug/.build-id/8b/28ab573be4a2302e1117964edede2e54ebbdbf.debug...don
e.
done.
(gdb) \textbf%core /tmp/core.collectd!\enter
[New LWP 2250]
[New LWP 2252]
[New LWP 2259]
[New LWP 2257]
[New LWP 2255]
[New LWP 2232]
[New LWP 2235]
[New LWP 2238]
[New LWP 2242]
[New LWP 2244]
[New LWP 2245]
[New LWP 2231]
[New LWP 2243]
[New LWP 2251]
[New LWP 2248]
[New LWP 2239]
[New LWP 2229]
[New LWP 2249]
[New LWP 2230]
[New LWP 2247]
[New LWP 2233]
[New LWP 2256]
[New LWP 2236]
[New LWP 2246]
[New LWP 2240]
[New LWP 2241]
[New LWP 2237]
[New LWP 2234]
[New LWP 2253]
[New LWP 2254]
[New LWP 2258]
[New LWP 2260]
Failed to read a valid object file image from memory.
Core was generated by `collectd -f'.
Program terminated with signal 7, Bus error.
#0 0xb7705f5d in memcpy ()
from /project/fli4l/.fbr/fbr-trunk-x86/buildroot/output/target/lib/libc.so.0
(gdb) \textbf%backtrace!\enter
#0 0xb7705f5d in memcpy ()
from /project/fli4l/.fbr/fbr-trunk-x86/buildroot/output/target/lib/libc.so.0
#1 0xb768a251 in rrd_write (rrd_file=rrd_file@entry=0x808e930, buf=0x808e268,
count=count@entry=112) at rrd_open.c:716
#2 0xb76834f3 in rrd_create_fn (
file_name=file_name@entry=0x808d2f8 "/data/rrdtool/db/vm-fli4l-1/cpu-0/cpu-i
nterrupt.rrd.async", rrd=rrd@entry=0xacff2f4c) at rrd_create.c:727
#3 0xb7683d7b in rrd_create_r (
filename=filename@entry=0x808d2f8 "/data/rrdtool/db/vm-fli4l-1/cpu-0/cpu-int
errupt.rrd.async", pdp_step=pdp_step@entry=10, last_up=last_up@entry=1386052459,
argc=argc@entry=16, argv=argv@entry=0x808cf18) at rrd_create.c:580
#4 0xb76b77fd in srrd_create (
filename=0xacff33f0 "/data/rrdtool/db/vm-fli4l-1/cpu-0/cpu-interrupt.rrd.asy
nc",
pdp_step=10, last_up=1386052459, argc=16, argv=0x808cf18) at utils_rrdcreate
.c:377
#5 0xb76b78cb in srrd_create_thread (targs=targs@entry=0x808bab8)
at utils_rrdcreate.c:559
#6 0xb76b7a8f in srrd_create_thread (targs=0x808bab8) at utils_rrdcreate.c:491
#7 0xb7763430 in ?? ()
from /project/fli4l/.fbr/fbr-trunk-x86/buildroot/output/target/lib/libpthread
.so.0
#8 0xb775e672 in clone ()
from /project/fli4l/.fbr/fbr-trunk-x86/buildroot/output/target/lib/libpthread
.so.0
(gdb) \textbf%frame 1!\enter
#1 0xb768a251 in rrd_write (rrd_file=rrd_file@entry=0x808e930, buf=0x808e268,
count=count@entry=112) at rrd_open.c:716
716 memcpy(rrd_simple_file->file_start + rrd_file->pos, buf, count);
(gdb) \textbf%print (char*) buf!\enter
$1 = 0x808e268 "RRD"
(gdb) \textbf%print rrd_simple_file->file_start!\enter
value has been optimized out
(gdb) \textbf%list!\enter
711 if((rrd_file->pos + count) > old_size)
712 {
713 rrd_set_error("attempting to write beyond end of file");
714 return -1;
715 }
716 memcpy(rrd_simple_file->file_start + rrd_file->pos, buf, count);
717 rrd_file->pos += count;
718 return count; /* mimmic write() semantics */
719 #else
720 ssize_t _sz = write(rrd_simple_file->fd, buf, count);
(gdb) \textbf%list 700!\enter
695 * rrd_file->pos of rrd_simple_file->fd.
696 * Returns the number of bytes written or <0 on error. */
697
698 ssize_t rrd_write(
699 rrd_file_t *rrd_file,
700 const void *buf,
701 size_t count)
702 {
703 rrd_simple_file_t *rrd_simple_file = (rrd_simple_file_t *)rrd_file->
pvt;
704 #ifdef HAVE_MMAP
(gdb) \textbf%print *(rrd_simple_file_t *)rrd_file->pvt!\enter
$2 = {fd = 9, file_start = 0xa67d0000 <Address 0xa67d0000 out of bounds>,
mm_prot = 3, mm_flags = 1}
Hier sieht man nach etwas ``Wühlen'', dass sich in dem rrd_simple_file_t-Objekt ein ungültiger Zeiger befindet (``Address ... out of bounds''). Im weiteren Debugging-Verlauf wurde deutlich, dass ein gescheiterter posix_fallocate-Aufruf die Ursache für den Programmabsturz war.
Wichtig hierbei ist, dass alle anzugebenden Pfade voll qualifiziert sind (/project/...) und dass man auch keine ``Abkürzungen'' (etwa ˜/...) verwendet. Wenn man dies nicht beachtet, kann es passieren, dass gdb die Debug-Informationen zur Anwendung und/oder zu den verwendeten Bibliotheken nicht findet. Die Debug-Informationen sind nämlich ais Platzgründen nicht direkt in dem untersuchten Programm enthalten, sondern in einer separaten Datei unterhalb des Verzeichnisses ˜/.fbr/fbr-<branch>-<arch>/buildroot/output/debug/ gespeichert.
Was fbr-make alles für Sie tun kann, können Sie sich mit dem Kommando fbr-make help ausgeben lassen.
Sie können sich alle verfügbaren FBR-Pakete sowie deren Versionen anschauen, indem Sie das Kommando fbr-make show-versions nutzen:
[commandchars=\\\{\}]
$ \textbf{fbr-make show-versions}\enter
Configured packages
acpid 2.0.20
actctrl 3.25+dfsg1
add-days undefined
[...]
Mit Hilfe des Kommandos fbr-make links-against <soname> können Sie sich alle Dateien in ˜/.fbr/fbr-<branch>-<arch>/buildroot/output/target anzeigen lassen, die gegen eine Bibliothek mit dem Bibliotheksnamen soname gebunden sind. Um beispielsweise alle Programme und Bibliotheken zu identifizieren, welche die libm (Bibliothek mit mathematischen Funktionen) verwenden, nutzen Sie das Kommando fbr-make links-against libm.so.0, da libm.so.0 der Bibliotheksname der libm-Bibliothek ist. Eine mögliche Ausgabe ist:
[commandchars=\\\{\}]
$ \textbf{fbr-make links-against librrd_th.so.4}\enter
Executing plugin links-against
Files linking against librrd_th.so.4
collectd usr/lib/collectd/rrdcached.so
collectd usr/lib/collectd/rrdtool.so
rrdtool usr/bin/rrdcached
Dabei steht in der ersten Spalte der Paketname und in der zweiten der (relative) Pfad zu der Datei, die gegen die angegebenene Bibliothek gebunden ist.
Um den Bibliotheksnamen für eine Bibliothek herauszufinden, können Sie readelf wie folgt nutzen:
[commandchars=\\\{\}]
$ \textbf{readelf -d ~/.fbr/fbr-trunk-x86/buildroot/output/target/lib/libm-0.9.33.2.so |}\enter
> \textbf{grep SONAME}\enter
0x0000000e (SONAME) Library soname: [libm.so.0]
(Nur) für fli4l-Team-Entwickler mit Schreibzugriff auf das fli4l-SVN-Repository ist das Kommando fbr-make version-changes interessant. Es listet alle FBR-Pakete auf, deren Version lokal modifiziert wurde, deren Version in der Arbeitskopie also von der Repository-Version abweicht. Damit kann der Entwickler sich einen Überblick über aktualisierte FBR-Pakete verschaffen, etwa bevor er die Änderungen ins Repo schreibt. Eine mögliche Ausgabe ist:
[commandchars=\\\{\}]
$ \textbf{fbr-make version-changes}\enter
Executing plugin version-changes
Package version changes
KAMAILIO: 4.0.5 --> 4.1.1
Hier sieht man sofort, dass das kamailio-FBR-Paket von der Version 4.0.5 auf die Version 4.1.1 aktualisiert worden ist.
Mit Hilfe des Kommandos fbr-make buildroot-menuconfig ist es zum einen möglich, die zu übersetzenden FBR-Pakete auszuwählen. Das ist nützlich, wenn Sie andere FBR-Pakete für den fli4l übersetzen möchten, die standardmäßig nicht aktiviert sind, aber im uClibc-Buildroot integriert sind, oder wenn Sie eigene FBR-Pakete aktivieren wollen. Zum anderen können andere, globale Eigenschaften des FBRs verändert werden, etwa die Version des verwendeten GCC-Compilers. Beim erfolgreichen Beenden des Konfigurationsmenüs wird die neue Konfiguration im Verzeichnis src/fbr/buildroot/.config gespeichert.
Beachten Sie jedoch bitte, dass solche Änderungen der
Toolchain-Konfiguration offiziell nicht unterstützt werden, weil die
resultierenden Binärprogramme mit hoher Wahrscheinlichkeit inkompatibel mit der
offiziellen fli4l-Distribution werden. Wenn Sie also Binärprogramme für Ihr
eigenes OPT benötigen und dieses OPT veröffentlichen wollen, sollten Sie keine
Toolchain-Einstellung verändern!
Mit dem Kommando fbr-make uclibc-menuconfig kann die Funktionalität der verwendeten uClibc-Bibliothek verändert werden. Beim erfolgreichen Beenden des Konfigurationsmenüs wird die neue Konfiguration in src/fbr/buildroot/package/uclibc/uclibc.config gespeichert.
Wie im letzten Abschnitt gilt auch hier: Eine Änderung ist mit hoher
Wahrscheinlichkeit nicht kompatibel mit der offiziellen fli4l-Distribution und
wird somit nicht unterstützt!
Mit Hilfe des Kommandos fbr-make busybox-menuconfig kann die Busybox in ihrer Funktionalität angepasst werden. Beim erfolgreichen Beenden des Konfigurationsmenüs wird die neue Konfiguration in src/fbr/buildroot/package/busybox/busybox-<Version>.config gespeichert.
Auch hier gilt: Eine Änderung ist
höchstwahrscheinlich nicht kompatibel mit der offiziellen fli4l-Distribution und
wird somit nicht unterstützt! Allenfalls das Ergänzen der Busybox um neue
Applets ist problemlos, solange Sie die so modifizierte Busybox nur auf Ihren
fli4l-Routern einsetzen (und nicht vom Nutzer Ihres OPTs den Einsatz einer
derart modifizierten Busybox verlangen).
Mit fbr-make linux-menuconfig bzw. fbr-make linux-<version>-menuconfig kann die Konfiguration aller aktivierten Kernel-Pakete bzw. eines bestimmten Kernel-Pakets vorgenommen werden. Beim erfolgreichen Beenden des Konfigurationsmenüs wird die neue Konfiguration in src/fbr/buildroot/linux/linux-<version>/dot-config-<arch> gespeichert.1.4
Wie im letzten Abschnitt gilt auch hier: Eine Änderung ist
höchstwahrscheinlich nicht kompatibel mit der offiziellen fli4l-Distribution und
wird somit nicht unterstützt! Allenfalls das Ergänzen des Linux-Kernels um neue
Module ist problemlos, solange Sie den so modifizierten Kernel nur auf Ihren
fli4l-Routern einsetzen (und nicht vom Nutzer Ihres OPTs den Einsatz eines
derart modifizierten Kernels verlangen).
Jedem der beschriebenen Kommandos geht eine Prüfung des FBRs auf Aktualität voraus. Wird eine Diskrepanz zwischen den Quellen, in denen sich fbr-make befindet (also entpacktes src-Paket oder SVN-Arbeitskopie) und dem FBR in ˜/.fbr/fbr-<branch>-<arch>/buildroot entdeckt, wird letzteres auf den neuesten Stand gebracht. Dabei werden neu dazugekommene FBR-Pakete integriert sowie alte, nicht mehr enthaltene FBR-Pakete gelöscht. Auch die Konfigurationen werden verglichen: FBR-Pakete mit veränderter Konfiguration sowie alle davon abhängigen FBR-Pakete werden neu gebaut. Dies stellt sicher, dass das FBR auf Ihrem Computer immer dem der fli4l-Entwickler entspricht (mit Ausnahme Ihrer eigenen FBR-Pakete unterhalb von ˜/.fbr/own/). Das bedeutet jedoch auch, dass Änderungen am offiziellen Teil der Buildroot-Konfiguration bei der nächsten Aktualisierung verloren gehen! Auch deshalb ist eine Rekonfiguration des FBRs (s.o.) somit nicht zu empfehlen, zumindest nicht, wenn Sie mit src-Paketen anstatt mit SVN-Arbeitskopien arbeiten. (Bei der Aktualisierung einer SVN-Arbeitskopie werden Ihre lokalen Konfigurationsänderungen und die Änderungen im SVN-Repository zusammengeführt, so dass das Problem der verlorenen Konfiguration hier nicht auftritt.) Hingegen können Sie Ihre eigenen FBR-Pakete problemlos umkonfigurieren, ohne dass es bei einer Aktualisierung zu Datenverlusten kommt.
Die Übersetzung der einzelnen FBR-Pakete wird über kleine Makefiles gesteuert. Will man eigene FBR-Pakete entwickeln, so muss man ein Makefile sowie eine Konfigurationsbeschreibung unter ˜/.fbr/own/<paket>/ ablegen. Wie diese aufgebaut sind und wie man daraus abgeleitet eigene Makefiles schreiben kann, wird in der Dokumentation des uClibc-Buildroots unter http://buildroot.uclibc.org/downloads/manual/manual.html#adding-packages ausführlich beschrieben.