Re: backups ? Kernelbau

Daniel E. Atencio Psille <dea(at)atencio.de> wrote:
> Ich bin auch mit dem GENERIC zufrieden, habe zwar bislang nur USB von
> den möglichen Peripherischnittstellen meines Laptops verwendet aber das
> kommt schon noch. Allerdings (5.2.1-RELEASE) hab' ich deutlich länger
> als die genannten 3-4 Stunden gebraucht, um mich durch die
> /sys/i386/conf/GENERIC und die /sys/conf/NOTES sowie die
> /sys/conf/i368.options zu hangeln. Mag daran liegen, dass ich gerne
> verstehe, was ich da mache (also immer wieder nach passenden manpages
> u.dgl. suchen, lesen, weitermachen, suchen, lesen ...). Letztendlich
> hab' ich es aufgegeben.

Das ist wohl eher die falsche Herangehensweise.

Zunächst kann man in den meisten Fällen ohnehin einfach den
GENERIC-Kernel benutzen, vor allem als Anfänger. Dinge,
die da nicht drin sind (z.B. Audiotreiber), kann man als
Modul nachladen. Dafür sind die Module ja schließlich da.

Will man dann doch mal einen eigenen Kernel bauen, hat das
meistens einen von drei Gründen:

 - Dinge rauswerfen, die man nicht braucht, oder die man
   auch lieber als Modul benutzen möchte. Dazu genügt es,
   sich sein dmesg anzuschauen und dann aus GENERIC (bzw.
   einer Kopie davon) die unnützen Sachen rauszuwerfen.
   Ggf. liest man dabei noch die eine oder andere Treiber-
   manpage. Das Durchackern von LINT bzw. NOTES oder gar
   *.options ist da völlig überflüssig.

 - Man möchte irgendwas statisch reincompilieren, was es
   nicht als Modul gibt (oder man kann/will aus irgendeinem
   Grund das Modul nicht verwenden). Dazu muß man nur die
   betreffende manpage lesen, und ggf. in LINT / NOTES den
   Abschnitt, der den gewünschten Treiber betrifft. Mei-
   stens sind das nur ein paar Zeilen.

 - Man möchte irgendwelche Optionen justieren (SYSV*, HZ,
   INCLUDE_CONFIG_FILE etc.). Normalerweise weiß man dann
   schon, was man tut, sonst käme man nicht auf die Idee,
   daß man da etwas dran drehen möchte. Aber auch sonst
   braucht man nur den zugehörigen Abschnitt in LINT bzw.
   NOTES zu lesen, oder die sonstige Dokumentation für
   diese Variable (manpage, Handbook).

Sich als Anfänger komplett durch LINT oder NOTES durchzu-
kämpfen, halte ich für Zeitverschwendung. Das bringt
eigentlich gar nichts, unter praktischen Gesichtspunkten.

Das kann man natürlich später einmal tun, wenn einen die
Neugierde packt und man genug Zeit übrig hat. Aber zum
Bauen eines Kernels ist das nicht notwendig.

> Ich sehe einen durchaus beträchtlichen Unterschied. In *config habe ich
> die Möglichkeit, mir zu jedem Eintrag eine (meist) aussagekräftige
> Erläuterung anzeigen zu lassen. Das ist mitunter bei der Entscheidung ob
> und welche Komponenten benötigt werden sehr hilfreich.

Das ist der falsche Ansatz. Ich finde, es ist eine graus-
liche Vorstellung, daß man erstmal _alles_ durchgehen muß,
um dann festzustellen, daß man vielleicht 5% davon benötigt.

Bei FreeBSD ist erstmal alles Wichtige in GENERIC drin oder
als Modul nachladbar (was in vielen Fällen sogar ganz auto-
matisch passiert, z.B. bei mount oder ifconfig).

Wenn man dann doch einmal etwas Zusätzliches benötigt, weiß
man ja normalerweise, worum es sich handelt, und kann dann
gezielt die manpage lesen, oder den zugehörigen Abschnitt
im Handbook, oder die jeweiligen Zeilen in LINT / NOTES.

> [...] Ich vermisse zwar
> ein paar (Linux spezifische?) Tools wie lspci, dmidecode, discover u.

Ich weiß nicht, was jene Tools tun, aber es gibt sicherlich
bei (Free)BSD Äquivalente dazu. »lspci« klingt z.B. so,
als wenn pciconf(8) Dein Freund wäre.

> [...] Und dazu dann noch diese doofen Implkationen, beispelsweise
> mit den Modulen. Bei Linux muss ich angeben, ob ich etwas als Modul
> haben will oder nicht, bei FreeBSD hab' ich gar keine Wahl, alles wird
> per se als Modul kompiliert und nur die in der Konfigurationsdatei
> angegebenen Optionen werden statisch eingebaut?

Genau im Gegenteil -- Bei FreeBSD hast Du die Wahl, ob Du
etwas als Modul laden möchtest, oder ob Du es statisch in
den Kernel hineincompilieren möchtest. Daß beim Bauen
eines Kernels per Default auch alle Kernelmodule neu gebaut
werden, ist eine andere Geschichte -- dadurch ist sicherge-
stellt, daß sie alle aktuell und »in sync« mit dem Kernel
sind. Wenn Du das nicht magst, kannst Du es aber auch in
/etc/make.conf abschalten (bzw. so einstellen, daß sie nur
bei einem »make world« neu gebaut werden).

> Nix dazu jefunge :/

Nich richtig jesucht. ;-)

> Da gelange ich doch zu der Auffassung, dass die
> Dokumentation für den Linux Kernel deutlich "besser" (im Sinne der
> Benutzerfreundlichkeit) gestaltet ist.

Dokumentation unter Linux ist grundsätzlich ein Problem.
Das beginnt schon damit, daß ich noch nie ein Linux gesehen
habe, das in Sachen Vollständigkeit und Aktualität der man-
pages auch nur annähernd an die BSDs heranreicht. Gerade
neulich wieder war ich auf einem Linux-Rechenr eingeloggt,
wo die in der ps(1)-manpage beschriebenen Optionen mit der
Realität nicht übereinstimmten, und das war kein Einzel-
fall.

Bei BSD sieht das ganz anders aus; es gibt praktisch zu je-
dem Furz eine manpage, und deren Pflege wird sehr ernst ge-
nommen. Fast alle Kernel-Treiber haben eine eigene manpage.
Man muß natürlich im Hinterkopf behalten, daß die manpages
nur die Referenz-Dokumentation eines UNIX-Systems darstel-
len. Übergreifende Dokumentationen, Einführungen und Tuto-
rien sind darin nicht enthalten -- dafür gibt es z.B. das
Handbook, die FAQ und die zahlreichen anderen Books und
Articles.

Wenn man von Linux kommt, ist BSD natürlich »anders«, und
man muß sich erstmal umgewöhnen, besonders wenn man gedank-
lich zimelich eingefahren ist mit den Linux-Konzepten.

»Die dunkle Seite der Macht ist schnell, leicht und ver-
führerisch!«

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"To this day, many C programmers believe that 'strong typing'
just means pounding extra hard on the keyboard."
        -- Peter van der Linden
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message