Muss seinen Kernel noch selber kompilieren?

**nopes** · 05.01.11, 21:39

Hallo Zusammen,

scheint mit hier am geeignetsten.

Lohnt es sich überhaupt noch seinen Kernel selber zu backen?
Ich frage mich das schon länger und bei Servern sehe ich das auch ein.

Aber was ist mit einem "ollen" Schreibtisch- oder Klapprechner? Hier will man doch eigentlich einen modularen Kern haben, ist es dann aber nicht absurd noch selber zu backen? Wenn doch die Distribution schon einen solchen liefert, der oben drein meist noch einige extra Patches hat.

Ich frage mich also, was es wohl für Gründe sind, die einem "Desktopler" davon überzeugen immer einen eigenen Kern zu erstellen.

**DrunkenFreak** · 05.01.11, 21:46

Meiner Meinung nach ist das so gut wie überall Überflüssig. Wenn man speziell auf einen Treiber angewiesen ist, bleibt einem nichts anderes übrig, aber sonst benutze ich überall den Standardkernel. Selbst auf Servern.

**nopes** · 05.01.11, 21:50

Ja diese Motivation ist mir bekannt, wer jemals auf einem VIA M10000 Videos sehen will, kommt nur schwerlich drumherum.

Allerdings hatte ich nach dem Patchen, Backen usw. ein nicht so stabiles System, also habe ich mir eine Hauppauge kaufen müssen, da wurde direkt unterstützt und ich konnte wieder die der Distro nutzen.

Naja inzwischen, ist die Hardware ja weiter

**derguteweka** · 05.01.11, 22:05

Moin,

Naja, man muss ihn ja nicht selber compilieren, aber man kanns halt (oder man kanns halt nicht, aber dann liegts an einem selber ;-) ).

Ob sich's lohnt, einen Kernel selber zu backen, sollte der Kernelbaecker schon selber wissen - wenn er's nicht weiss, dann tut's auch ein Fertigkernel.

Stabilitaet haengt nicht an Distributionen. Ich hab' hier seit ein paar Jahren ausschliesslich LFS auf Rechnern am Laufen und da gabs noch keine Stabilitaetsprobleme.

Gruss
WK

Rain_maker · 06.01.11, 09:56

Zitat von DrunkenFreak

Meiner Meinung nach ist das so gut wie überall Überflüssig. Wenn man speziell auf einen Treiber angewiesen ist, bleibt einem nichts anderes übrig, ...

Und selbst das ist in den allermeisten Fällen unnötig.

Sobald es um einen Treiber geht, der im verwendeten Distributionskernel als Modul vorliegt, hat man zumindest die Möglichkeit ihn durch ein in irgendeiner Form modifiziertes Modul zu ersetzen (Stichwort Backport).

Beispiel gefällig?

Hier läuft eine openSUSE 11.2 mit 2.6.31, der Kernel bietet zwar OOTB-Unterstützung für mein GSM-Modem (Treiber option.ko), aber der Treiber hatte ab und zu so seine kleineren Problemchen, vor allem bei s2ram/s2disk und die üblichen Tricks (Module beim Suspend entladen und beim Aufwachen neu laden) funktionierten nicht so ganz zuverlässig.

Mit dem selben Treiber aus neueren Kernelversionen (ab 2.6.33/34 IIRC) waren diese Problemchen dann auch weg, nur dazu würde ich niemals den gesamten Kernel neu basteln, schlussendlich kam das hier heraus.

Code:

rpm -qilv option-kmp-desktop 
Name        : option-kmp-desktop           Relocations: (not relocatable)
Version     : 2.6.37_2.6.31.14_0.4              Vendor: (none)
Release     : 0.0                        Build Date: Sa 18 Dez 2010 11:19:04 CET
Install Date: Sa 18 Dez 2010 11:20:25 CET      Build Host: Fatboy.site
Group       : System/Kernel                 Source RPM: option-2.6.37-0.0.src.rpm
Size        : 110152                           License: GPL
Signature   : (none)
Summary     : USB Driver for GSM modems
Description :
This package contains a kernel module for USB GSM modems backported from linux 2.6.37.

The driver will be called "option.ko".
Distribution: (none)
drwxr-xr-x    2 root    root                        0 Dez 18 11:18 /lib/modules/2.6.31.14-0.4-desktop
drwxr-xr-x    2 root    root                        0 Dez 18 11:18 /lib/modules/2.6.31.14-0.4-desktop/updates
-rw-r--r--    1 root    root                    81280 Dez 18 11:18 /lib/modules/2.6.31.14-0.4-desktop/updates/option.ko
-rw-r--r--    1 root    root                    28872 Dez 18 11:18 /lib/modules/2.6.31.14-0.4-desktop/updates/usb_wwan.ko

Natürlich muss man nicht gleich alles paketieren, das ginge auch "zu Fuß" oder als nicht zu unterschätzende, ebenfalls recht saubere Lösung mit dkms.

Greetz,

RM

**DrunkenFreak** · 06.01.11, 17:16

Alles Erbsenzähler hier

Überlese dann bitte das Wort speziell nicht

**jeebee** · 06.01.11, 19:17

Also ich back mir seit neuestem wieder eigene Kernel (u.a. um den sched_autogroup patch zu haben).

--> Wenn du experimentelle Features o.ä. haben willst, ist's sinnvoll.

**delix** · 06.01.11, 20:08

Mein selbstgebackener (aber eigentlich nur "entschlackter" Distri-) Kernel auf einem alten Rechner hat mehrere Hundert Dateien (meist Treiber) und ein paar MB Speicherplatz weniger. Das erstere erleichtert die Übersicht, und das letztere macht bei sso alten Krücken auch was aus......

Rain_maker · 06.01.11, 21:29

Zitat von DrunkenFreak

Alles Erbsenzähler hier

Und was hat das mit Erbsenzählerei zu tun?

Es ging darum, daß man in den allerwenigsten Fällen für ein Treibermodul den gesamten Kernel neu bauen muss.

Zitat von DrunkenFreak

Überlese dann bitte das Wort speziell nicht

Bla?

Aber bitte, ich brauchte _speziell_ diesen einen Treiber für mein GSM-Modem, weil der im Distrokernel ein Problem hatte.

Statt nun einen gesamten Kernel >= 2.6.33/34 zu bauen, habe ich _speziell_ diesen einen Treiber zurück portiert.

Zufrieden?

**oziris** · 06.01.11, 21:42

Es war eigentlich noch nie wirklich nötig einen Kernel selbst zu konfigurieren.
... aber wenn man ihn selbst konfiguriert hat man einige zusätzliche Optionen und kann ihn auf seine Bedürfnisse anpassen.
Man kann z.B. alle nötigen Sachen für's Booten hinein tun (anstatt als Module), braucht dann keine initrd mehr und kann so geringfügig schneller booten.

**derRichard** · 07.01.11, 11:38

Zitat von jeebee

Also ich back mir seit neuestem wieder eigene Kernel (u.a. um den sched_autogroup patch zu haben).

und was bringt dir das?
autogroup bringt nur sehr bedingt mehr leistung auf einem normalem desktop.

//richard

**jeebee** · 07.01.11, 22:40

@richard: hast du's ausprobiert?

Ich finde, dass sich das System flüssiger anfühlt, insbesondere wenn ich für die Uni wieder mal was grösseres am kompilieren bin (im stil von make -j64, damit das ganze cpu-bound und nicht io-bound ist) und währenddessen surfen will.

**oziris** · 08.01.11, 00:56

Genügen Dir nice und ionice nicht?

**derRichard** · 08.01.11, 11:33

Zitat von jeebee

@richard: hast du's ausprobiert?

Ich finde, dass sich das System flüssiger anfühlt, insbesondere wenn ich für die Uni wieder mal was grösseres am kompilieren bin (im stil von make -j64, damit das ganze cpu-bound und nicht io-bound ist) und währenddessen surfen will.

hast du >64 cpus?
weil sonst ist das make komplett unsinnig.
aber genau bei solch unsinnigen dingen bringt der patch was.

//richard

**jeebee** · 08.01.11, 13:36

Naja, ich mag mich nicht streiten. Die gefühlte Performance bei grösseren Compiles ist besser mit dem Patch, das reicht mir.

@nice/ionice: die machen was orthogonal anderes und verringern die Priorität von make. Das ist nun überhaupt nicht was ich will. Ich will ein normal priorisiertes make, welches die Desktop-Latency (zb von Firefox) nicht beeinträchtigt.