Kernel kompilieren

[Tronar]

'n Abend,

weiß einer von Euch eine wirklich erschöpfende Auflistung und Erklärung aller "device"s, "options" und sonstigen Anweisungen in der Kernelkonfiguration? Das Handbuchkapitel 8.4 behandelt nur die wichtigen Punkte, die beiden Dateien /usr/src/sys/i386/conf/NOTES und /usr/src/sys/conf/NOTES behandeln manche Optionen sehr knapp - und manche werden gar nicht aufgeführt.
Beispielsweise stieß ich in Kap. 14.10 des Handbuchs auf eine Möglichkeit "options FAST_IPSEC", die in keiner der eben erwähnten Dokumentationen aufgeführt ist. Und bei so banalen Themen wie der seriellen Schnittstelle habe ich auch lange nicht durchgeblickt: Für den ganz gewöhnlichen PC sind wohl nur die Treiber "sio" oder "uart" von Belang, andere wie "puc" oder "scc" braucht man nur für spezielle Hardware. Den wesentlichen Unterschied zwischen "sio" und "uart" werde ich auch noch herausfinden.
Daß für praktisch jeden Treiber eine detaillierte Manpage existiert, ist ein echter Vorteil gegenüber Linux. Aber oft enthalten weder die Manpages noch die oben erwähnte Dokumentation Hinweise der Art "Sie brauchen diese Option, wenn ..." oder "Wenn Sie diesen Treiber verwenden, müssen Sie auch / dürfen Sie nicht ... verwenden."
Auch finde ich nicht viel Information darüber, welche Komponenten ich in Module auslagern kann und wie man diese dann baut. Beispielsweise hat mein Laptop ein etwas schrottiges "Alps"-Touchpad, das den "psm"-Treiber öfters zum Krepieren bringt. Wenn er nicht fest im Kernel ist (geht das?), bringen "kldunload psm" und "kldload psm" die Sache wahrscheinlich sofort wieder in Ordnung.

Also: Gibt es irgendwo ausführlichere und vor allem vollständigere Auslassungen über Kernel & Co.?

MfG
Tronar

PS: Es geht nicht allein darum, alles zusammenzukriegen, damit meine Kiste optimal läuft. Es geht auch darum, überhaupt zu sehen, was für Möglichkeiten der Kernel für den Unternehmungslustigen bereithält.

 

[Yamagi]

Also, eine solche Liste gibt es leider noch nicht. Aber, wir können ja eine schreiben. Zum Beispiel erst einmal hier sammeln und später einen Wiki-Artikel drauß machen. Ich fange mal an:

"options FAST_IPSEC" ist nicht mehr aktuell. Früher hatte FreeBSD die IPSEC-Implementierung des Kame-Projektes (das sind die Japaner, die IPv6 entwickelt und die Referenzimplementierung auf Basis von FreeBSD geschrieben haben). Das war allerdings recht langsam, auch da es die Änderungen an FreeBSD 5 und später nicht berücksichtigte. Sam Leffler schrieb daraufhin ein neues IPSEC und nannte dies FAST_IPSEC, da es eben mehrklich schneller ist. FreeSBD 6 hatte daher zweimal IPSEC, das alte und das neue. Mit FreeBSD 7 flog das alte IPSEC raus und FAST_IPSEC wurde zu "options IPSEC". Die Option benötigt "device crypto", sonst baut der Kernel nicht.

"sio" ist ein Treiber für eine Reihe alter Intel-Schnittstellen, die sich am Rechner meist als RS232 zeigen. Da die meisten modernen Rechner damit kompatibel sind, funktioniert er noch. "uart" hingegen ist ein generischer Treiber, welcher nicht nur die Geräte von sio unterstützt, sondern auch eine Menge mehr. Ich meine mich zu erinnern, dass "sio" mit FreeBSD 8 sterben wird. "puc" ist ein Multiplexer, damit können Schnittstellentreiber wie "uart" und "sio" Chips ansprechen, die hinter einer Brücke hängen. Z.B. auf klassischen PCI-Einsteckkarten. Brauchst du normalerweise nicht. Außerdem gibt es eine Reihe spezieller Treiber für nicht standardkonforme oder spezielle Schnittstellen. "scc" ist ein solcher, aber auch "digi".

"psm" kann nicht als Modul gebaut werden. Es ist - technisch gesehen - eine Abstraktion des alten IBM AT-Keyboards, welches bei einem x86-Rechner eine zwingende Komponente ist. Du kannst keinen Kernel ohne den Treiber "atkbdc" und "atkbd" bauen, da "psm" fest damit vertrickt es, ihn selbst auch nicht als Modul.

 

[mousaka]

Also, eine solche Liste gibt es leider noch nicht. Aber, wir können ja eine schreiben. Zum Beispiel erst einmal hier sammeln und später einen Wiki-Artikel drauß machen.

Gute Idee, sowas habe ich auch schon öfters schmerzlich vermisst.

Für einen späteren Wiki-Artikel schlage ich folgende Bereiche vor (als Tabelle gestaltet):

• Eintrag
• Modul möglich (ja/nein)
• Zweck
• Benötigt
• FreeBSD Versionen (bis / seit)
• Architekturen

Ein Beispiel von Yamagi:

• device psm
• nein
• eine Abstraktion des alten IBM AT-Keyboards, welches bei einem x86-Rechner eine zwingende Komponente ist
• device atkbdc, device atkbd
• alle
• i386, amd64

mousaka

 

[xcvb]

Tolle Idee, da schließe ich mich an.

Denn auch nach dem Studium der NOTES Dateien und Handbuch und Google, etc. bleiben oft noch Fragen offen...okay wenn man richtig Zeit investiert kann man sich alles irgendwie von hier und da zusammen suchen aber so eine zentrale Anlaufstelle hier im Wiki wäre da eine echte Hilfe.....

 

[Kamikaze]

http://wiki.bsdforen.de/freebsd/kernel_konfiguration

Ich habe mal die Tabellen angelegt.

 

[Yamagi]

Ich habe die Tabelle für die Optionen einmal angepasst. "options" wird beim Bauen des Kernels zu einer Make-Variable. Also z.B. -DIPSEC. Die wiederum löst ein #ifdef im Source aus. Eine Option kann also niemals ein Modul ergeben. Module können aber von Optionen abhängen.

 

[Tronar]

Also, eine solche Liste gibt es leider noch nicht. Aber, wir können ja eine schreiben. Zum Beispiel erst einmal hier sammeln und später einen Wiki-Artikel drauß machen. Ich fange mal an:

Wau! Daß aus meiner Anfrage gleich ein neues Projekt werden würde ... do legst di nieda!
Übrigens, mousaka, würde ich für die Beschreibung eher die Angaben aus den Manpages verwenden, etwa beim "psm":
"Treiber für die PS/2-Maus und ähnliche Zeigegeräte"
Daß es ursprünglich die Abstraktion eines Tastaturtreibers darstellt, ist doch von untergeordneter Bedeutung.

Wenn aus der Sache was Ordentliches wird, können wir vielleicht um die Aufnahme ins Handbuch bitten oder jedenfalls in die offizielle Dokumentation.

"psm" kann nicht als Modul gebaut werden. Es ist - technisch gesehen - eine Abstraktion des alten IBM AT-Keyboards, welches bei einem x86-Rechner eine zwingende Komponente ist. Du kannst keinen Kernel ohne den Treiber "atkbdc" und "atkbd" bauen, da "psm" fest damit vertrickt es, ihn selbst auch nicht als Modul.

Das ist ärgerlich. Damit gibt es dann wohl keine Möglichkeit, dem Treiber einen Reset angedeihen zu lassen - außer durch Reboot.
Dann muß halt doch eine separate Maus her.

Danke jedenfalls für die ganzen Detailauskünfte
Tronar

 

[Tronar]

Noch eine Frage zu den Modulen:

Ich kann sicher davon ausgehen, daß jeder Treiber, für den in /usr/src/sys/modules ein Unterverzeichnis existiert, als Modul gebaut werden kann. Gilt auch die Umkehrung dieser Aussage?
Oder kennt jemand von Euch ein Gegenbeispiel, d. h. ein mögliches Modul, für das es keinen Eintrag in /usr/src/sys/modules gibt, z. B. weil es immer als "Beifang" eines anderen Treibers gebaut wird?
Ggf. hätte man damit also eine vollständige (?) Auflistung aller Module.

Schönes Wochenende
Tronar

 

[Tronar]

'n Abend!
Ist vielleicht nicht die beste Idee, an einen Uralt-Thread anzuknüpfen, aber das gehört irgendwie zum Thema.
Zunächst ein Abschnitt aus der Kernelkonfiguration:

device ppp # Kernel PPP
options PPP_BSDCOMP # PPP BSD-compress support
options PPP_DEFLATE # PPP zlib/deflate/gzip support
options PPP_FILTER # enable bpf filtering (needs bpf)

Der "device"-Anweisung entspricht ein Kernelmodul, während die "options" hier nur die Funktionalität des Moduls erweitern.
Wenn ich mich nun aber entscheide, "ppp" als separates Modul (namens "if_ppp.ko") zu bauen anstatt fest in den Kernel ... wie stelle ich dann die "options" ein oder aus?

Tronar

 

[Kamikaze]

Ich denke genau so. Du lässt die Options so in der Kernel-Konfiguration.

 

[Tronar]

Ich denke genau so. Du lässt die Options so in der Kernel-Konfiguration.

Ah ja! Daran schließe ich gleich noch eine Frage an:
Yamagi bemerkte in diesem Thread einmal, "options" könnten nie ein Modul ergeben. Wie ist das aber z. B. mit "options CD9660"? Das baut doch nichts anderes als den Dateisystemtreiber "cd9660.ko" in den Kernel hinein. Der Unterschied zum oben erwähnten "PPP_DEFLATE" wäre somit:
- Lasse ich "options CD9660" weg, kann ich es als externes Modul benutzen.
- Lasse ich "options PPP_DEFLATE" weg, kann ich es gar nicht benutzen.
Sehe ich das richtig?

 

[Yamagi]

Es gibt ein paar Ausnahmen. Wenn du im Kernel "options BEISPIEL" nutzt, macht make(1) daraus einen Aufruf in der art -DBEISPIEL. Dies löst im Sourcecode wiederum Anweisungen aus, die Dinge verändern. Und diese Dinge können unter Umständen auch sein, dass das Ding nicht mehr als Modul gebaut werden kann oder das es fest im Kernel landet. Betrifft die meisten Dateissysteme und ein bisschen was von Netzwerkkrams.