Re: O.T. Vanilla Kernel Quellen
Hallo Liste, so jetzt gugg ich mittlerweile also doch etwas blöd! Heißt das alles jetzt dass Suse sozusagen am Kernel rumpfuscht und dann nicht fähig ist einen mindestens gleichwertigen Kernel anzubieten? für was gibt es denn dann die ganzen Programmierer wenn Suse meint sie könne alles besser? Mit freundlichen Grüßen Mike
Am Fre, 20 Sep 2002 schrieb Michael Messner:
so jetzt gugg ich mittlerweile also doch etwas blöd! Heißt das alles jetzt dass Suse sozusagen am Kernel rumpfuscht und dann nicht fähig ist einen mindestens gleichwertigen Kernel anzubieten?
Nein, das ist sicher so nicht richtig. Das Kernel-Development ist eine, wie Du Dir sicher vorstellen kannst, recht komplexe Geschichte, wo nicht immer alle einer Meinung sind, ob ein Feature sinnvoll ist oder nicht bzw. ob eine bestimmte Art der Realisierung gewählt werden sollte. Dazu kommt, daß die Kernel-Entwicklung nicht gerade straff durchorganisiert ist (zumindest zu Zeiten, wo Linus selbst noch den stabilen Kernel maintainte), so daß Patches verloren gehen, einfach nicht angenommen werden, weil sie ihm nicht gefielen (z.B. der IMHO sehr sinnvolle /proc/config.gz Patch) oder aber für noch nicht genug getestet für den stabilen Kernel erschienen, dafür aber für eine ganze Menge Systeme trotzdem geeignet sind (z.B. die Journaling Filesysteme, mittlerweile sind sie ja fast alle im Kernel, XFS zumindest in 2.5, aber das hat lange gedauert) Deswegen sind fast alle Distributoren dazu übergegangen, ihre mitgelieferten Kernel mit Patches auszustatten. Da sind durchaus auch sehr viele sinnvolle Sachen dabei, aber manchmal geht halt was schief oder war wirklich noch nicht ausreichend getestet oder so. Dafür sind manche Patches auch notwendig, um Fehler im vanilla-Kern auszubügeln. Das ist aber kein SuSE-spezifisches Problem. Habe gerade gestern noch auf einem Debian-Woody mit heftigen Problemen bei der ALSA-Installation gekämpft, die sich erst lösen ließen, als ich den mitgelieferten 2.4.18-686 mit einem selbstkompilierten 2.4.18er ersetzt habe. Also das Patchen macht in gewissen Grenzen schon Sinn. Ich würde es trotzdem begrüßen, wenn die Distributoren auf Ihren CDs noch zusätzlich einen Vanilla-Kern dazupacken würden und die Patches, die sie verwendet haben, einzeln im Quellcode liefern (ich weiß, daß es die auf H. Mantels Seite gibt). Hinzu kommt, daß man IMHO, wenn man etwas Ahnung hat, sowieso besser damit fährt, seinen eigenen Kernel zu kompilieren und dann genau das reinzupacken, was man braucht, die InitRD loszuwerden etc. Ich mache das seit einiger Zeit so und entscheide dann sehr restriktiv, welche Patches mir sinnvoll erscheinen (im Moment der config.gz, der low-latency und der preempive-Patch, die beiden letzteren aber nur für Desktop-Systeme, auf einem Server würde ich sie nicht laufen lassen) Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Christoph Maurer wrote:
Also das Patchen macht in gewissen Grenzen schon Sinn. Ich würde es trotzdem begrüßen, wenn die Distributoren auf Ihren CDs noch zusätzlich einen Vanilla-Kern dazupacken würden und die Patches, die sie verwendet haben, einzeln im Quellcode liefern (ich weiß, daß es die auf H. Mantels Seite gibt).
Es gibt ja folgende Kernel-Pakete: k_deflt, k_smp (und die 386 Versionen), kernel-source und dann halt das Paket woraus alle anderen erzeugt werden: kernel-source-2.4.18.SuSE-35.nosrc.rpm in dem letztgenannten sollte wie es sich fuer ein src.rpm gehoert, die original Software und alle zusaetzlichen Patches enthalten. Schau mal in der Quelltext-Serie nach. CD6, zq2 Peter
Hallo,
* "Michael Messner"
Heißt das alles jetzt dass Suse sozusagen am Kernel rumpfuscht und dann nicht fähig ist einen mindestens gleichwertigen Kernel anzubieten?
Das ist kein /rumpfuschen/ sondern /patchen/. Und das tut nicht nur SuSE. Jede Distribution setzt Patches, die ihr sinnvoll erscheinen, jeder Endnutzer mit etwas Erfahrung kann das tun.
für was gibt es denn dann die ganzen Programmierer wenn Suse meint sie könne alles besser?
Wirf mal einen Blick auf den Kernel Traffic von Zack Brown, wenn Dich das Thema interessiert: http://kt.zork.net/kernel-traffic/ Gruss, Andreas -- [andreas] > du -hs mutt-manual 328k mutt-manual *WOW!* [andreas] > du -hs gnus-manual 1.9M gnus-manual *GASP!*
Michael Messner wrote:
so jetzt gugg ich mittlerweile also doch etwas blöd! Heißt das alles jetzt dass Suse sozusagen am Kernel rumpfuscht und dann nicht fähig ist einen mindestens gleichwertigen Kernel anzubieten?
für was gibt es denn dann die ganzen Programmierer wenn Suse meint sie könne alles besser?
Na, na, mit so einem Rundumschlag schaffst Du Dir sicher keine Freunde. SuSE pfuscht nicht am Kernel rum, sondern spielt ge- wisse Patches ein, die die Kernel-Entwickler bei SuSE fuer wichtig oder sinnvoll erachten, oder auch Patches, die einen bekannten Bug im Vanilla-Kernel beheben. Das macht quasi jeder Distributor, und in gewissem Rahmen ist dies sicher auch sinn- voll. Leider sind diese Patches aeusserst schlecht dokumentiert!!! Zwar kann man sie im Verzeichnis von H. Mantel auf dem SuSE FTP-Server bekommen, aber man muss sich schon ein wenig aus- kennen, um diese Patches auch nur annaehernd verstehen zu koen- nen. Viele davon sind durchaus sinnvoll, z.B. hat SuSE eben das Filesystem xfs schon mit im Kernel integriert, waehrend man im stable-Tree des Vanilla-Kernels vergeblich danach su- chen wird. Ich hatte neulich das Problem, dass ich den SuSE-Kernel durch einen Vanilla-Kernel ersetzt habe, und auf einmal gab es beim Booten Probleme mit "blogd" - das hat mich schwer verwundert, bis klar war, dass fuer das Feature ein SuSE-Patch benoetigt wird. Tja, nur welcher der vielen ist es nun, und haengt die- ser Patch evtl. von anderen Patches ab...? Das ist alles sehr undurchsichtig, und da laeuft mir persoenlich die Entwicklung dann einfach zu sehr auseinandern, wenn ich einen SuSE-Kernel nicht mehr durch einen Vanilla-Kernel ersetzen kann, ohne dass Fehlermeldungen auftauchen. Beim 2.4.18-4GB von der letzten SuSE-Distribution ging eben einiges schief, was IDE angeht. IDE ist momentan eh schwer im Umbruch, schau nur mal ins Archiv der Kernel-Mailingliste oder ins Changelog des Kernels. IMHO sollte so ein Bug aber im Stan- dardkernel einer Distribution nicht vorkommen (es ist ja ein hausgemachter Fehler, kein Fehler im Vanilla-Kernel, denn der zeigt das entsprechende Verhalten nicht und laeuft stabil). Ich habe hier auch schon den 2.4.19-4GB, der auf der neuen SuSE Distri 8.1 dabei sein wird, getestet und bin mir nicht sicher, ob der stabil laueft - insbesondere in Verbindung mit VIA Chips kommt es mitunter zu Instabilitaeten und Kernel-Panics. Wir sind aber noch am Rumpfrimeln und Erkunden.... Beim 2.4.18-4GB gingen uns hier >30.000 Dateien ueber den Jordan (Backup war natuerlich da, aber trotzdem!), die sich aufgrund des IDE-Bugs im Kernel dann spaeter in lost+found wiederfanden. Nur mit Hilfe von Ralf Corsepius (Danke, Ralf!) sind wir damals dem eigentlichen Pro- blem (2 IDE-Festplatten an einem VIA-Chip,...) auf den Grund ge- kommen. So schoen und sinnvoll manche Patches auch sein moegen, ich denke, sie muessen in Zukunft einfach besser dokumentiert werden und es muss klar sein, welche Patches voneinander abhaengen und welcher Patch fuer was verantwortlich ist. Sonst endet das alles frueher oder spaeter im absoluten Chaos und die Schere zwischen Vanilla-Kernel und den Distributions-Kerneln wird immer groesser. Gruesse aus KA, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
participants (5)
-
Andreas Kneib -
Christoph Maurer -
Michael Messner -
Peter Wiersig -
Thomas Hertweck