Optimierte Version von /etc/init.d/rcS für Dbox2

[rhabarber1848]

Hi,

wie einige von Euch bereits verfolgt haben, wurde im IDE-Menü-Thread
die Idee für sinnvoll erachtet, die seit längerem geplante Verbesserung
des Startskripts /etc/init.d/rcS nun endlich durchzuführen.
(Der Leidensdruck ist endlich zu groß geworden )

Dazu erst einmal der Ist-Zustand:
Es geht um die Datei cdk/root/etc/init.d/rcS.m4

Hier werden bereits m4-Makros eingesetzt, allerdings
nur für $customizationsdir, um rcS mit eigenem Code
ergänzen zu können und ein Kernel 2.6-abhängiges
m4 define, welches aber noch nicht genutzt wird...
Das bedeutet, dass in rcS bei jedem Bootvorgang
die Kernelversion abgefragt wird und je nach Ergebnis
nur bestimmte Codeteile ausgeführt werden. Besser
wäre es, wenn die nicht benötigten Codeteile gar
nicht im Image landen.

To-Do-Liste:

• rsS.insmod entfernen, wird direkt über die Kernelversion abgehandelt
• in Abhängigkeit der Kernelversion nicht benötigte Codeteile entfernen
• in Abhängigkeit von --enable-ide/mmc Kernelmodule laden
• in Abhängigkeit des verwendeten Dateisystems /var mounten, ohne fstab dabei zu nutzen
• /etc/fstab wird in Squashfs/Cramfs-Images nach /var/etc/fstab verschoben, /etc/fstab ist dann ein Link dorthin, /var ist nicht mehr in fstab enthalten, s.o.

[seife]

Ich würde noch eine andere Methode "anbieten":

Anstelle einer monolithischen rcS werden in {var,}/etc/init.d/ mehrere kleine init-skripten angelegt, die jeweils ein Ding machen. Diese werden der Reihe nach ausgeführt, fast wie auf einem "Richtigen" Linux-System.

Der Vorteil: man kann einfach zusätzliche Sachen (automounter, beliebige daemons etc) hinzufügen, ohne im rcS rumpfuschen zu müssen (was ja, "dank" m4, immer ein echtes Gefrickel ist). Man könnte im CVS ein "01-mount-jffs2root" und ein "01-mount-squashfsroot" haben, wovon nur eines ins image kommt und das dann die richtige var-Partition kennt. Ganz ohne variablen etc.

Der Nachteil: wir würden auf der dbox2 evtl. eine halbe Sekunde langsamer booten.

Auf der Tripledragon habe ich das schon erfolgreich im Einsatz, wie das aussehen kann kannst du hier sehen: http://gitorious.org/tripledragon-build ... l-root/etc (ja, ist noch nicht perfekt, die init-skripten müssten eigentlich aus "once" (start) und nicht aus "sysinit" (rcS) abgearbeitet werden, aber das ist leicht zu fixen)

Langfristig halte ich das für
* besser portierbar
* besser maintainbar
* übersichtlicher

Ich werde das für mich auf jeden Fall so machen.

[rhabarber1848]

Auf der Tripledragon habe ich das schon erfolgreich im Einsatz

Ich habe Interesse daran, dass der Code für die verschiedenen
Platformen nicht zu sehr auseinanderdriftet. Deshalb werde ich
mir Deine Lösung nächste Woche anschauen. Wie sind eigentlich
Deine Pläne für die Einbindung des TD-Codes ins Tuxbox-CVS?

[seife]

Auf der Tripledragon habe ich das schon erfolgreich im Einsatz

Ich habe Interesse daran, dass der Code für die verschiedenen
Platformen nicht zu sehr auseinanderdriftet. Deshalb werde ich
mir Deine Lösung nächste Woche anschauen. Wie sind eigentlich
Deine Pläne für die Einbindung des TD-Codes ins Tuxbox-CVS?

Oha, das wird ne längere Erklärung

Zuerst: ich habe keinerlei Interesse, für TD aus dem CDK zu bauen. Meine Buildscripten funktionieren, ohne unnötigen automake-overhead, und sie sind sehr einfach zu durchschauen.

Ich habe mal angefangen, die Frontends zu mergen (weil ich irgendwann gemerkt habe, dass Sachen, die auf der TD schon lange funktionierten, auf dream und dbox noch kaputt waren ), allerdings ist das alles momentan auf "Halt", weil ich erst schauen will, ob ich mit dem HD1-Neutrino-Code weitermache oder auf der CVS-Basis. Im Prinzip funktioniert auf der TD auch alles, was ich brauche, also ist es für mich soweit "fertig".

Einige Sachen sind auch mit der aktuellen Architektur (mehrere Daemons/GUI, die aber alle keine eindeutig definierte Aufgabe haben, sondern alle alles machen) nicht ordentlich machbar, insofern ist z.B. der Movieplayer auf der TD ein übler Hack (er muss Messages an zapit senden, damit zapit einen ioctl macht... ), der nicht wirklich "upstream-fähig" ist.

Es hängt also im Prinzip davon ab, wie der HD1-Source aussieht. Je nachdem gibt es 3 Möglichkeiten:

1) der HD1-Source ist ok und ich portiere den auf alle boxen (d-box2, dream 500, TD, HD1). Dabei werde ich vermutlich die Fixes, die wir in den letzten Jahren in neutrino eingebaut haben, dort auch einbauen müssen, sowie einiges an der GUI fixen, so dass sie auf verschiedenen Framebuffergrössen läuft etc.
2) der HD1-Source ist nicht ok, dann muss ich selbst (CVS)-neutrino von "viele daemons, eine GUI" auf "nur noch eine GUI und die früheren daemons laufen als threads in der GUI" oder so ähnlich umbauen und HD-Tauglich machen. Das mit dem Framebuffer muss trotzdem gefixt werden.
3) wie 2), aber ohne "daemon -> single application" Konversion. Dann müsste man die Layering violations im neutrino fixen (receiver-Hardware wird nur von zapit bedient => movieplayer und aufnahme muss ins zapit, neutrino macht *nur* noch die GUI), was eher noch mehr Arbeit wäre, und trotzdem die alten Bugs in der daemon-Kommunikation provoziert.

Ich hoffe auf 1) ;-)

Wenn ich am Wochenende dazu komme versuche ich mal, einen proof-of-concept mit "neuen" initscripten zu machen.

[Barf]

Hintergrund: In oldmake gab es rcS und rcS als separat verwaltete Dateien. Sie haben unheimlich von einander weggedriftet. Meine Erklärung ist dass die für die Devs, die mit einem davon gearbeitet hat, die Andere unintressant war. rcS.m4 war von mir entworfen, um die Beide single-source-ig pflegen zu können. Ganz konsequenzt wäre dann rcD.insmod als Objekt ganz zu eliminieren, (wird bei der Installation nur in rcS umbenannt) was ich leider 2006 nicht durchgeschaut habe -- und die Community hat es bis zu 2009 gedauert!!

Anstelle einer monolithischen rcS werden in {var,}/etc/init.d/ mehrere kleine init-skripten angelegt, die jeweils ein Ding machen. Diese werden der Reihe nach ausgeführt, fast wie auf einem "Richtigen" Linux-System.

Ich glaube ich habe schon in 2006 sowas vorgeschlagen, und es war nicht gut angekommen... Portabilität, wiederverwendbarket etc sprechen dafür.

Ich glaube wir sollen uns in Richtung Konfigurierbarkeit des installiertes Systems bewegen, weg von alle die configure-optionen. So ist es durchaus denkbar, zukünftig z.B. ide- und/oder mmc-Unterstützung mittels ein "tuxbox-rpm"-Paket nachzuinstallieren, wurde einige Kernelmodule und ein init-script enthalten.

Ich bin auch der Meinung, dass es Sinnvoll ist, den Filesystem Hierarchy Standard (FHS) einzuhalten. Nicht weil es genial oder verpflichtend ist, sondern um Tuxbox konform zu allgemeine Konventionen zu halten. So soll es /etc/passwd, /etc/fstab heissen, und soll so angesprochen werden, auch falls sie Links (oder Mountpunkte) sind.

[*]rsS.insmod entfernen, wird direkt über die Kernelversion abgehandelt

Unbedingt, siehe oben

[*] in Abhängigkeit der Kernelversion nicht benötigte Codeteile entferne

Unbedingt, kernelversion sind nicht zum Updaten geplant.

[*] in Abhängigkeit von --enable-ide/mmc Kernelmodule laden

Aus früher genannten Grunden, lieber nicht

[*] in Abhängigkeit des verwendeten Dateisystems /var mounten, ohne fstab dabei zu nutzen
[*] /etc/fstab wird in Squashfs/Cramfs-Images nach /var/etc/fstab verschoben, /etc/fstab ist dann ein Link dorthin, /var ist nicht mehr in fstab enthalten, s.o.

Ich glaube dass es sinnvoll ist, /var in fstab zu behalten, auch falls ein initscript es mountet ohne fstab. Vgl auch meine Bemerkungen um FHS.

... ohne im rcS rumpfuschen zu müssen (was ja, "dank" m4, immer ein echtes Gefrickel ist)

Sieht nicht wirklich als Diskussionswünsch aus... Ich bin jederfalls anderer Meinung, ins besonders wenn [ba]sh-Programmieren die Alternative ist.

[dbt]

To-Do-Liste:
[*] in Abhängigkeit von --enable-ide/mmc Kernelmodule laden

Ich denke du meinst nur "das sie geladen werden". Würde im Falle, wenn das über die GUI gregelt wird (was ich grad versuche zu machen), komplett aus rcS rausfallen. Deshalb hatte ich in die rcS einen Aufruf für das zusätzliche init.drives script eingebaut, welches in einer /etc/init.d/init.drives Standardversion vorliegt wo alles was mit Modulen und mounts zu tun hat schon mal drin steht. Dann kommt die beschreibbare Version hinzu, also ein /var/etc/init.d/init.drives, welches sich dann zur Laufzeit anpassen ließe. So war mein Plan zumindest. In wie weit man in die Standardversion in Abhängigkeit von --enable-ide/mmc oder irgendwas etwas reinschreibt müsste man mal schauen, glaube aber eigentlich auch nicht, dass es notwendig ist, weil man einiges davon auch zur Laufzeit machen kann.

[*] in Abhängigkeit des verwendeten Dateisystems /var mounten, ohne fstab dabei zu nutzen
[*] /etc/fstab wird in Squashfs/Cramfs-Images nach /var/etc/fstab verschoben, /etc/fstab ist dann ein Link dorthin, /var ist nicht mehr in fstab enthalten, s.o.[/list]

Nun gut, das wird momentan durch die BB abgedeckt. Die Version mit den Links hatte ich schon mal probiert und war nicht sehr erfolgreich. Prinzipiell würde ich die Verwendung von fstab bevorzugen. Ist einfach nur praktisch. und ist letztlich linux-typisch. Dass man hier "ausnahmsweise" auf eine /var/etc/fstab zurückgreifen muss, wenn man, wie in aktuellem Fall, eine beschreibbare Version haben muß, liegt nunmal an den Voraussetzungen die uns vorgegeben sind (squashfs...). Eine bessere Variante fällt mir dazu leider auch nicht ein. Höchstens noch, wenn es denn ginge, eine Extra jffs-Partition die parallel neben /var auch in /etc vorhanden ist.

... ohne im rcS rumpfuschen zu müssen (was ja, "dank" m4, immer ein echtes Gefrickel ist)

Mit dem Gefrickel, muss ich eigentlich zustimmen, die m4-Syntax ist schon was feines wäre aber verschmerzlich wenn es weiterhilft.

[seife]

Ich finde generierte skripten immer unpraktisch, da man nicht so einfach Änderungen Testen und wieder einchecken kann. Man muss in der Praxis immer erst bauen, damit man sieht, ob auch das rauskommt, was man sich gewünscht hat. Soviel zum Thema m4. Ausserdem finde ich die m4-Syntax schon recht barock, aber das ist Geschmackssache Das soll aber nicht die Diskussion erschlagen.

Wenn wir aber zu mehreren kleinen Initscripten übergehen (etc/init.d/S??*), dann ist es evtl. auch nicht mehr notwendig, die per m4 zu erzeugen, weil viele davon systemunabhängig sein werden (dbox, dreambox, ...) und die paar systemabhängigen (module laden etc.) halt in mehreren Versionen vorhanden sein könnten.