Kapitel 18. Weiterführende Themen

Zurzeit gibt es nur ein Buch über die Interna von FreeBSD, “The Design and Implementation of the FreeBSD Operating System” von Marshall Kirk McKusick und George V. Neville-Neil, ISBN 0-201-70245-2, das sich auf FreeBSD 5.X konzentriert.

Allgemeines Wissen über UNIX® kann allerdings in den meisten Fällen auf FreeBSD angewendet werden.

Eine Liste finden Sie im entsprechenden Abschnitt der Bibliographie.

Genauere Informationen finden Sie im Artikel FreeBSD unterstützen. Wir können Hilfe immer gut gebrauchen!

Derzeit existieren vier aktive/halbaktive Zweige im FreeBSD-CVS-Repository. In früheren Zweigen ändert sich wenig, daher gibt es nur vier aktive Entwicklungszweige:

• RELENG_7 bzw. 7-STABLE

• RELENG_8 bzw. 8-STABLE

• RELENG_9 bzw. 9-STABLE

• HEAD bzw. -CURRENT oder 10-CURRENT

HEAD ist keine wirkliche Bezeichnung für einen Zweig, wie die anderen. Es ist lediglich eine symbolische Konstante für “den aktuellen, nicht verzweigten Entwicklungsstrom”, auf den wir uns einfach als -CURRENT beziehen.

Derzeit steht -CURRENT für den 10.X-Entwicklungsstrom. Der 9-STABLE-Zweig (RELENG_9) wurde von -CURRENT im September 2011 und der 8-STABLE-Zweig (RELENG_8) im August 2009 von -CURRENT abgespalten.

Eine Anleitung dazu finden Sie im Artikel FreeBSD Release Engineering.

Das ist beabsichtigt. Wie der Name schon andeutet, erstellt make world alle Systemdateien von Grund auf neu. Sie können also sicher sein, am Ende eine saubere, konsistente Umgebung zu haben (das ist der Grund, warum es so lange dauert).

Falls die Umgebungsvariable DESTDIR während der Ausführung von make world oder make install definiert ist, werden die neu erstellten Binaries unter ${DESTDIR} in einem zum installierten identischen Verzeichnisbaum abgelegt. Einige zufällige Kombinationen von Änderungen von Shared Libraries und Neuerstellungen von Programmen können hierbei jedoch ein Scheitern von make world verursachen.

Die CVsup-Server gleichen sich stündlich mit dem Hauptserver ab. Allerdings findet der Abgleich nicht zur gleichen Zeit statt, daher können einige Server neuere Quellen bereitstellen als andere Server. Alle Server stellen jedoch Quellen bereit, die maximal eine Stunde alt sind. Wäre cvsup.FreeBSD.org ein Round-Robin-Eintrag im DNS, der Benutzern einen zufälligen Server zuteilt, könnten beim zweiten Lauf von CVsup ältere Quellen als beim ersten Lauf heruntergeladen werden.

Ja, Sie können das tun, ohne den gesamten Quellbaum herunterzuladen, indem Sie die Einrichtung CTM benutzen.

Bei neueren BSD-basierten Systemen gibt es eine Option -b zu split(1), die das Splitten von Dateien an willkürlichen Bytegrenzen erlaubt.

Hier ist ein Beispiel aus /usr/src/release/Makefile.

ZIPNSPLIT=              gzip --no-name -9 -c | split -b 1392k -

Lesen Sie bitte den Artikel FreeBSD unterstützen.

Und Danke, dass Sie darüber nachdenken!

Von: Frank Durda IV <[email protected]>

Kurz gesagt gibt es nur wenige I/O-Ports über die PnP-Karten antworten, wenn der Host fragt, ob jemand da ist. Wenn die PnP-Erkennungsroutine startet, fragt sie, ob irgendwelche PnP-Karten vorhanden sind und alle PnP-Karten antworten mit ihrer Modellnummer auf demselben Port, von dem sie auch gelesen haben. Die Erkennungsroutine erhält also ein geodertes “Ja” auf diese Frage. Mindestens ein Bit wird bei dieser Antwort gesetzt sein. Die Erkennungsroutine ist dann in der Lage, dafür zu sorgen, dass Karten mit Modellnummern (zugeordnet von Microsoft®/Intel®) kleiner als X “off-line” gesetzt werden. Sie prüft dann, ob immer noch Karten da sind, die auf die Frage antworten. Falls die Antwort 0 war, sind keine Karten mit IDs größer X vorhanden. Die Erkennungsroutine wird daraufhin anfragen, ob Karten unterhalb X vorhanden sind. Schließlich setzt die Erkennungsroutine alle Karten größer als X - (limit / 4) off-line und wiederholt die Frage. Wenn diese halbbinäre Suche nach IDs in Folge genügend oft wiederholt worden ist, wird die Erkennungsroutine schließlich alle in einem Rechner befindlichen PnP-Karten identifiziert haben und das mit einer Iterationszahl sehr viel kleiner als 2⁶⁴.

Die IDs bestehen aus zwei 32-Bit-Feldern (daher 2⁶⁴) + acht Bit Prüfsumme. Die ersten 32 Bit sind die Herstellerkennung. Es wurde zwar nicht bestätigt, aber es wird angenommen, dass unterschiedliche Kartentypen desselben Herstellers unterschiedliche 32-Bit Herstellerkennungen besitzen können. 32 Bit nur für eindeutige Hersteller zu benötigen, scheint etwas übertrieben.

Die niedrigen 32 Bit sind eine Seriennummer oder etwas anderes, das die betreffende Karte einzigartig macht. Die Hersteller dürfen niemals eine zweite Karte mit denselben niedrigen 32 Bit herstellen, es sei denn, die höheren 32 Bit sind unterschiedlich. Sie können also mehrere Karten des selben Typs im Rechner haben und die gesamten 64 Bit bleiben stets eindeutig.

Die 32-Bit-Gruppen können niemals nur aus Nullen bestehen. Das erlaubt es, bei der binären Suche zu Beginn nur auf von Null verschiedene Bits zu achten.

Wenn das System alle vorhandenen Karten-IDs identifiziert hat, reaktiviert es jede Karte - eine nach der anderen (über dieselben I/O-Ports) und ermittelt, welche Ressourcen von der jeweiligen Karte benötigt werden, welche Wahlmöglichkeiten für Interrupts bestehen usw. Alle Karten werden abgefragt, um diese Informationen zusammenzustellen.

Diese Informationen werden dann mit Informationen aus allen ECU-Dateien auf der Festplatte oder mit im MLB-BIOS verdrahteten Informationen verknüpft. Die ECU- und BIOS-PnP-Unterstützung für Hardware auf dem MLB ist für gewöhnlich künstlich und was die Peripheriegeräte tun ist nicht wirklich echtes PnP. Durch die Untersuchung der BIOS-Informationen und der ECU-Informationen können die Erkennungsroutinen jedoch die von PnP-Geräten benutzten Ressourcen so ändern, dass vermieden wird, dass bereits von anderen Geräten benutzte Ressourcen verwendet werden.

Dann werden die PnP-Geräte nochmals besucht und ihre I/O, DMA, IRQ und Memory-Map-Adressen werden zugeordnet. Die Geräte werden an diesen Stellen sichtbar werden und dort bis zum nächsten Reboot verbleiben. Allerdings hindert Sie auch nichts daran, sie zu verschieben, wohin Sie wollen.

Im obigen Teil wurde sehr viel vereinfacht, aber die grundlegende Idee sollte klar geworden sein.

Microsoft hat einige der primären Druckerstatusports für PnP übernommen, da keine Karte diese Adressen für die entgegengesetzten I/O-Zyklen decodiert. Ich habe während der frühen Überprüfungsperiode des PnP-Vorschlags eine echte IBM Druckerkarte gefunden, die Schreibzugriffe auf dem Statusport decodiert hat, aber Microsoft hat nur “tough” gesagt. Also schreiben sie auf den Druckerstatusport, um Adressen zu setzen, benutzen zusätzlich diese Adresse + 0x800 und einen dritten I/O-Port zum Lesen, der irgendwo zwischen 0x200 und 0x3ff liegen kann.

FreeBSD Versionen stellen seit Februar 2003 Major-Numbers für Geräte automatisch zur Laufzeit bereit (lesen Sie devfs(5)), damit ist das nicht mehr nötig.

Als Antwort auf die Frage nach alternativen Layoutverfahren für Verzeichnisse ist das Schema, das derzeit benutzt wird, unverändert von dem, das ich 1983 geschrieben habe. Ich habe das Vorgehen für das originale Fast-Filesystem geschrieben und es niemals überarbeitet. Es funktioniert gut, wenn es darum geht, zu verhindern, dass Zylindergruppen volllaufen. Wie viele von Ihnen angemerkt haben, funktioniert es schlecht für find. Die meisten Dateisysteme werden von Archiven erstellt, die mit einer Tiefensuche (also ftw) erstellt wurden. Diese Verzeichnisse werden über die Zylindergruppen hinweg entfaltet und erzeugen denkbar ungünstigste Voraussetzungen für zukünftige Tiefensuchen. Falls man die Gesamtzahl der zu erstellenden Verzeichnisse wüsste, wäre die Lösung die, (gesamt / fs_ncg) pro Zylindergruppe zu erstellen, bevor fortgefahren wird. Offensichtlich müsste man eine Heuristik erstellen, um die Zahl zu schätzen. Sogar die Benutzung einer kleinen, fixen Zahl, z.B. 10, würde eine Verbesserung um Größenordnungen ausmachen. Um Wiederherstellungen von normalem Betrieb (wo der derzeitige Algorithmus vermutlich sinnvoller ist) zu unterscheiden, könnten Sie die Clusterung von bis zu 10 benutzen, wenn sie alle innerhalb eines 10-Sekunden-Fensters durchgeführt würden. Jedenfalls ist mein Schluss, dass dies ein fruchtbares Gebiet für Experimente ist.

Kirk McKusick <[email protected]>, September 1998

Hier ist eine typische Kernel-Panic

Fatal trap 12: page fault while in kernel mode

fault virtual address   = 0x40
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xf014a7e5
stack pointer           = 0x10:0xf4ed6f24
frame pointer           = 0x10:0xf4ed6f28
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 80 (mount)
interrupt mask          =
trap number             = 12
panic: page fault

Wenn Sie eine Meldung wie diese sehen, reicht es nicht, sie einfach zu reproduzieren und sie einzusenden. Der Wert des Instruktionszeigers ist wichtig; leider ist er auch konfigurationsabhängig. Mit anderen Worten variieren die Werte abhängig von dem Kernel-Image, das Sie tatsächlich benutzen. Wenn Sie ein GENERIC Kernelimage von einem der Snapshots benutzen, dann ist es für jemand anderen möglich, die fehlerhafte Instruktion herauszufinden, aber wenn Sie einen angepassten Kernel benutzen, können nur Sie uns sagen, wo der Fehler auftrat.

Was Sie tun sollten, ist folgendes:

Wie dem auch sei, der beste Weg, den Grund für eine Panik herauszufinden, ist der, einen Crash-Dump festzuhalten und dann kgdb(1) zu benutzen, um den Stack im Crash-Dump zurückzuverfolgen.

Jedenfalls ist die Methode, die ich normalerweise benutze, folgende:

Der make(1)-Prozess wird zwei Kernel erstellt haben: /usr/obj/usr/src/sys/MYKERNEL/kernel und /usr/obj/usr/src/sys/MYKERNEL/kernel.debug. kernel wurde als /boot/kernel installiert, während kernel.debug als Quelle für Debuggersymbole für kgdb(1) benutzt werden kann.

Um sicherzustellen, dass ein Crash-Dump erhalten bleibt, müssen Sie /etc/rc.config editieren und dumpdev so setzen, dass es auf Ihre Swap-Partition zeigt. Das bewirkt, dass die rc(8)-Skripte den Befehl dumpon(8) benutzen, um Crash-Dumps zu ermöglichen. Sie können dumpon(8) auch manuell ausführen. Nach einer Panik kann der Crash-Dump mit savecore(8) wiederhergestellt werden; wenn dumpdev in /etc/rc.conf gesetzt ist, werden die rc(8)-Skripte savecore(8) automatisch ausführen und den Crash-Dump unter /var/crash ablegen.

Wenn Sie den Crash-Dump wiederhergestellt haben, können Sie den Stack mit kgdb(1) so zurückverfolgen:

% kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0
(kgdb) backtrace

Beachten Sie, dass es mehrere Seiten mit wertvollen Informationen geben könnte; idealerweise sollten Sie script(1) benutzen, um sie alle festzuhalten. Wenn Sie das vollständige Kernelimage mit allen Debugginginformationen benutzen, müssten Sie exakt die Zeile des Kernel-Sourcecodes finden, wo die Panik aufgetreten ist. Für gewöhnlich müssen Sie den Stack von unten an zurückverfolgen, um die genaue Ereignisabfolge, die zum Crash führte, zurückzuverfolgen. Sie können kgdb(1) auch zum Ausdrucken der Inhalte verschiedener Variablen oder Strukturen benutzen, um den Systemstatus zum Zeitpunkt des Absturzes zu untersuchen.

Die ELF-Werkzeuge machen die in einem Executable definierten Symbole dem dynamischen Linker nicht standardmäßig sichtbar. Konsequenterweise werden dlsym()-Suchen nach Handlern aus Aufrufen von dlopen(NULL, flags) diese Symbole nicht finden können.

Wenn Sie mit dlsym() nach im Hauptexecutable eines Prozesses vorhandenen Symbolen suchen wollen, müssen Sie das Executable mit der Option --export-dynamic von ld(1) linken.

Standardmäßig beträgt der Adressraum des Kernels 1 GB (2 GB für PAE) auf i386. Wenn Sie einen netzwerkintensiven Server (z.B. einen großen FTP- oder HTTP-Server) betreiben, oder ZFS verwenden möchten, kann es sein, dass Sie der Meinung sind, dass das nicht ausreichen.

Fügen Sie die folgende Zeile zu ihrer Kernelkonfigurationsdatei hinzu, um den verfügbaren Speicher zu erhöhen und erstellen Sie dann einen neuen Kernel:

options KVA_PAGES=N

Um den richtigen Wert von N zu bestimmen, teilen Sie den gewünschte Größe des Addressraumes (in Megabyte) durch vier (z.B. beträgt er 512 für 2 GB).