staging.inyokaproject.org

Hallo, der Artikel ist fertig und kann aus der Baustelle verschoben werden. Das zugehörige Skript Kernel/make-ubuntu-kernel.sh wurde anscheinend bereits verschoben, der Artikel selbst aber nicht.

Hallo,

der Artikel Baustelle/Kernel/Kompilierung aus der Wiki ist laut Diskussionsseite ja schon fertig. Ich habe die Anleitung ausprobiert, es fehlt nur eine Kleinigkeit.

Bei Baustelle/Kernel/Kompilierung (Abschnitt „Kompilieren-Die-Ubuntu-Methode“) fehlt lediglich der Hinweis, dass zum Kompilieren keine .config-Datei im source-Verzeichnis liegen darf. Dann klappt es.

Der Artikel ist sehr ausführlich und entspricht großteils https://help.ubuntu.com/community/Kernel/Compile - ich bin dafür, einen so wertvollen Artikel von der Baustelle zu nehmen.

Grüße, Ben

Danke für den Hinweis, ich habs eingefügt.

Moin Moin!

Schöner Artikel!

Das Skript wurde automatisch mit Baustelle/Kernel verschoben, Inyoka ist beim Verschieben untergeordneter Anhänge großzügiger, als bei Unterseiten. 😉

Zum Artikel:

Variable Teile von Befehlen mit <Variable> darzustellen, finde ich ungünstig, da die Sonderzeichen ihre eigene Bedeutung (Umleitungen) haben. Stattdessen nutze ich durchgehend Großbuchstaben, also VARIABLE.

Die Installation von git brauchst du nicht beschreiben; stattdessen reicht ein Git-Eintrag im Wissensblock.

Bei #Installieren in der Warnbox noch einen Link auf die Stelle, wo die entsprechenden Einstellungen vorgenommen werden.

Ansonsten IMHO fertig.

Gruß, cornix

cornix schrieb:

Variable Teile von Befehlen mit <Variable> darzustellen, finde ich ungünstig, da die Sonderzeichen ihre eigene Bedeutung (Umleitungen) haben. Stattdessen nutze ich durchgehend Großbuchstaben, also VARIABLE.

Geändert.

Die Installation von git brauchst du nicht beschreiben; stattdessen reicht ein Git-Eintrag im Wissensblock.

Ich habe git in den Wissensblock eingefügt, allerdings habe ich die "Installationsbeschreibung" drin gelassen, da sie doch nur aus einer Zeile besteht (Angabe des Paketnamens). Damit hat man dann schon alles, was man für diesen Artikel über git wissen muss.

Bei #Installieren in der Warnbox noch einen Link auf die Stelle, wo die entsprechenden Einstellungen vorgenommen werden.

Geändert.

Ganz kleine Kleinigkeiten habe ich noch geändert und den Artikel verschoben nach Kernel/Kompilierung.

Danke für den ausführlichen Artikel zu dem sicherlich nicht leichten Thema, barcc! 👍

Verlinkt war er schon in Kernel, sonst noch sinnvolle Stellen dafür?

Gruß, cornix

Zumindest Kernelcheck sollte mMn. durchaus im Unterpunkt "eigenen Kernel bauen" erwähnt werden. Das Tool macht Vieles leichter. Gut, der BFS ist zugegeben sinnfrei, der Patch für "Automatic Process Group Scheduling" bringt allerdings einiges an performance (siehe hier). Wenn selbst Linus beeindruckt ist, soll das schon etwas heißen.

Klar, kann man alles machen. Die Idee hinter dem automatischen Gruppieren von Prozessgruppen liest sich auch gut. Ich gebe auch zu, dass ich meine Kernel im allgemeinen mit -j6 baue und nicht mit -j16 -j32 oder 64. Mir fehlt es da irgendwie an der Rechentechnik, die solch ein Vorgehen sinnvoll macht. Was allerdings spürbar ist, das Scheduling der Kernel hat sich im letzten Jahr sehr verbessert, die neuen .37 und .38 sollen in dieser Hinsicht auch nochmal zulegen. Dann ist aber die Anleitung für diese doch recht experimentelle Art und Weise der Beschleunigung hinfällig, da dann diese Änderungen poliert und eingearbeitet sind.

Wenn man mal ehrlich ist, ist der Ubuntu-Kernel schon recht performant und responsiv. Die .36er im Standard auch. Das hat mich davon abgehalten, die Schrauberei mit eigenen Kerneln in der letzten Zeit zu betreiben. Ich habe momentan auch noch einen .37-rc7 am Laufen, der die Lust am Selberbauen und Selbstkonfigurieren noch mal deutlich reduziert. Das Bauen der .37er lief auf meinem Notebook auf einem .36-2. Während der Zeit habe ich normal weitergearbeitet, ohne Geschwindigkeitseinbußen. Natürlich sollten die Links aufgenommen werden, aber die zwingende Notwendigkeit fehlt irgendwo.

Kernelcheck muss ich mir mal anschauen, da bin ich überhaupt nicht im Thema. Das Einzige, was ich bei Lust und Laune in meine Vanilla-Kernel einbaue, ist das tracing für ureadahead, das bringt bei Systemstart wirklich was. Dieser Patch sollte bei Kernelbau erwähnt werden, wenn nicht schon geschehen. Ein selbst gebauter Ubuntu-Kernel aus der Mainline-Schiene sollte minimal wenigstens diesen Patch enthalten. Wenn man dann selbst baut, gehört natürlich auch das Group-Scheduling dazu. Die Zeit, die man beim Selbstbauen benötigt, holt man allerdings über die Lebensdauer des Kernels nicht wieder rein, das sollte auch ganz deutlich geschrieben werden.

Genau dieser Zeitaufwand wird mit Kernelcheck fast hinfällig. Gibt es einen Patch für das Tracing für ureadahead? Hast du da einen Link parat?

Klar doch: Das Ding ist in den Source von ureadahead. Zur Sicherheit hier noch einmal.

Für welchen Kernel ist der Patch? Ich habs gerade beim 2.6.36-2 versucht, bekam aber leider diese Meldung:

patching file fs/open.c
Hunk #1 FAILED at 31.
Hunk #2 succeeded at 890 with fuzz 2 (offset -151 lines).
1 out of 2 hunks FAILED -- saving rejects to file fs/open.c.rej

Was fange ich damit an?

Der ist aus den aktuellen Quellen. Kannst Du Dir mit apt-get source ureadahead ziehen. Den .36-2 habe ich damit noch nicht gepatcht. Sekunde, muss grade mal umbooten.

Das ist der Inhalt der Datei open.c.rej:

--- fs/open.c
+++ fs/open.c
@@ -31,6 +31,9 @@
 #include <linux/falloc.h>
 #include <linux/fs_struct.h>
 
+#define CREATE_TRACE_POINTS
+#include <trace/events/fs.h>
+
 int vfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 {
 	int retval = -ENODEV;

Leider habe ich keinen Ansatz, wo ich den Code in der open.c einfügen sollte, die angegebene Zeile sieht anders aus.

auch patch geht zurück in eine Zeit, als Schlaghosen, lange Haare und LSD in waren. Mag vielleicht was damit zu tun haben. Die Zeilen werden direkt hinter den Includes eingefügt. Da hat aber schon jemand was anderes hingeschrieben. also greift der nur bis .35 Ich tausche mal den entsprechenden Part aus. Das Werkzeug ist halt aus einer Zeit, als IBM noch Immer Besser Manuell bedeutete.

Hab ich mir immer mal gewünscht, Patches per Hand umschreiben.

Ich bastel derweil schonmal an einem Artikel über Kernelcheck.