[erledigt] modulare init-skripte anstatt monolithischer rcS

Kreuzuebersetzer, Diskussion über Änderungen im Tuxbox-CDK und Tuxbox-CVS
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

[erledigt] modulare init-skripte anstatt monolithischer rcS

Beitrag von seife »

Hallo,

wie hier http://forum.tuxbox-cvs.sourceforge.net ... 25#p369425 angekündigt, habe ich mal einen proof-of-concept gemacht, um aus der grossen rcS mehrere kleine init-skripten zu machen.

Getestet habe ich es auf der dm500. Der tarball (Inhalt von cdk/root_dream/etc/init.d) ist hier: new-init.tar.gz

So sieht das dann bei mir aus:

Code: Alles auswählen

dm500 login: root


BusyBox v1.14.3 (2009-08-25 13:21:23 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ > cd /etc/init.d/
/etc/init.d > ls -l
-rwxr-xr-x    1 root     root         1339 Aug 25 14:27 K30autofs
-rwxr-xr-x    1 root     root         1478 Aug 25 14:27 S01mount
-rwxr-xr-x    1 root     root          123 Aug 25 14:27 S02devicelinks
-rwxr-xr-x    1 root     root          246 Aug 25 14:27 S10network
-rwxr-xr-x    1 root     root          131 Aug 25 14:27 S15syslogd
-rwxr-xr-x    1 root     root           82 Aug 25 14:27 S20inetd
-rwxr-xr-x    1 root     root         1339 Aug 25 14:27 S30autofs
-rwxr-xr-x    1 root     root          218 Aug 25 14:27 S75gui
-rwxr-xr-x    1 root     root          672 Aug 25 14:27 functions
-rwxr-xr-x    1 root     root           70 Aug 25 14:27 rcK
-rwxr-xr-x    1 root     root          575 Aug 25 14:27 rcS
-rwxr-xr-x    1 root     root         1030 Aug 25 14:27 start_neutrino
"functions" enthält Funktionen, die von mehreren Skripten gebraucht werden:

Code: Alles auswählen

/etc/init.d > cat functions
# common functions for init scripts

get_TZ() {
        [ -e /var/etc/TZ ] && read TZ < /var/etc/TZ && return
        [ -e /etc/TZ ]     && read TZ < /etc/TZ
}

run_initscripts() {
        if [ "x$1" == xstop ]; then
                action="stop"
                files="/var/etc/init.d/K* /etc/init.d/K*"
        else
                action="start"
                files="/var/etc/init.d/S* /etc/init.d/S*"
        fi

        names=$(for file in $files ; do echo ${file##*/} ; done | sort -u)

        for name in $names; do
                if [ -x "/var/etc/init.d/$name" ]; then
                        echo "${action}ing /var/etc/init.d/$name ..."
                        /var/etc/init.d/$name $action
                elif [ -x "/etc/init.d/$name" ]; then
                        echo "${action}ing /etc/init.d/$name ..."
                        /etc/init.d/$name $action
                fi
        done
}
"rcS" ist nicht maschinenunabhängig, da z.B. auf der dream das head.ko geladen werden muss, bevor vieles andere gemacht werden kann. Das könnte man aber noch in ein extra "sysinit" skript auslagern.

Gestartet wird das aus einer sehr einfachen /etc/inittab:

Code: Alles auswählen

/etc > cat inittab
# ::sysinit:/etc/init.d/sysinit # unused
::once:/etc/init.d/rcS

# this sucks
::askfirst:-/bin/sh

::restart:/sbin/init
::ctrlaltdel:/sbin/reboot
::shutdown:/etc/init.d/rcK
rcS wird aus ":once:" und nicht aus ":sysinit:" ausgeführt, damit man immer eine Konsole auf der seriellen Schnittstelle hat (die wird erst nach ":sysinit:" geöffnet), sonst sperrt man sich sehr schnell mal aus, wenn man beim Experimentieren etwas "verpfuscht" ;)

Leider kann ich es momentan nicht auf der dbox testen, aber auch dort sollte es ziemlich ähnlich gehen.

Der Startvorgang geht so:
- es werden alle Skripte in /etc/init.d/ und /var/etc/init.d/, die mit "S" beginnen, der Reihe nach ausgeführt
- /var/etc/init.d hat eine höhere Priorität als /etc/init.d/, also wenn in beiden Verzeichnissen ein "S99foo" liegt, wird das in /var/etc/init.d/ ausgeführt.

Beim Herunterfahren ist es dasselbe, nur das die Skripte, die mit "K" beginnen ausgeführt werden.

Damit man dasselbe Skript als start-(S)- und stop-(K)-skript verwenden kann, wird den skripten noch der Parameter "start" bzw. "stop" mitgegeben, den die auswerten können.

Bei mir funktionierts ;)
dbt
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 19:18

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von dbt »

Wenn es uns weiterhilft käme das für meinen Teil schon mal in die Tüte. Was die Wartung angeht, wäre das sicher einfacher als mit m4.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

Ich mach heute ne "Kinderzimmerbox" fertig, insofern kann ich es evtl auch noch auf der dbox2 ausprobieren / implementieren. Sollte fast einfacher sein, als auf der dream (die dream hat soviel legacy-crap und support für usb-boot etc. in den initskripten, da weiss ich nie, was weg kann und was nicht)
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

So, hier: newinit.diff ist eine Version, die bei mir mit kernel 2.6 bootet. Den Patch in cdk/root/etc anwenden.

Da ist noch einiges zu tun im Makefile.am, es sind auch nur die (für mich ;)) wichtigen Sachen drin, aber der Rest würde sich dann Schritt für Schritt ergeben.

Viel Spass ;)
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

So, habe es nochmals überarbeitet: newinit-2.diff (in cdk/ mit "patch -p0" einspielen)

Wird mit "--enable-new-init" beim Configure aktiviert.
Bootet mit Kernel 2.4 und 2.6. Die configure/Makefile.am-Sachen sind noch nicht perfekt, aber es macht, soweit ich sehe, nichts mehr kaputt, wenn es nicht aktiviert ist. So würde ich es gerne erst mal einchecken, damit man von da aus weitermachen kann

Nicht gefallen tut mir momentan z.B. dass inittab.newinit nach inittab kopiert wird, das müsste man irgendwann mal besser machen.

Wenn man nur noch diese Methode hätte, wäre es natürlich auch einfacher ;)
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

seife hat geschrieben:Wenn man nur noch diese Methode hätte, wäre es natürlich auch einfacher ;)
Sehe ich auch so, wenn wir umstellen, dann richtig.
Aber bis dahin fehlt afaics noch einiges, oder?
Wann wird z.B. tuxmail oder dropbear mit Deiner Methode gestartet?
dwilx

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von dwilx »

Warum nicht einen Branch dafür anlegen? Wäre das nicht die übliche Vorgehensweise, um ausgiebig testen zu können? :-?
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

rhabarber1848 hat geschrieben:
seife hat geschrieben:Wenn man nur noch diese Methode hätte, wäre es natürlich auch einfacher ;)
Sehe ich auch so, wenn wir umstellen, dann richtig.
Aber bis dahin fehlt afaics noch einiges, oder?
Wann wird z.B. tuxmail oder dropbear mit Deiner Methode gestartet?
Wenn jemand ein Initskript dafür schreibt ;)
dixidix hat geschrieben:Warum nicht einen Branch dafür anlegen? Wäre das nicht die übliche Vorgehensweise, um ausgiebig testen zu können? :-?
Weil wir CVS verwenden. Da sind Branches echt bäh und anstrengend.
dbt
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 19:18

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von dbt »

seife hat geschrieben:So, habe es nochmals überarbeitet: newinit-2.diff (in cdk/ mit "patch -p0" einspielen)

Wird mit "--enable-new-init" beim Configure aktiviert.
Bootet mit Kernel 2.4 und 2.6. Die configure/Makefile.am-Sachen sind noch nicht perfekt, aber es macht, soweit ich sehe, nichts mehr kaputt, wenn es nicht aktiviert ist. So würde ich es gerne erst mal einchecken, damit man von da aus weitermachen kann
...
Wie siehts aus? Ich würde sagen mach das einfach, wäre nicht schlecht, wenn man das in Angriff nehmen würde.
Würde das am Ende darauf hinauslaufen, dass "--enable-new-init" auch komplett wegfallen würde, wenn es denn mal läuft?
Mit einem Branch zu arbeiten, wäre zwar angebracht, aber wir wissen ja, was das wieder bedeuten würde. :wink:
Weil wir CVS verwenden. Da sind Branches echt bäh und anstrengend.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

dbt hat geschrieben:Ich würde sagen mach das einfach
Prinzipiell bin ich dafür, die Änderung vorzunehmen.
Im Vorgriff darauf habe ich deshalb heute die OpenVPN-
Sachen eingecheckt, damit es bei den neuen Startskripts
berücksichtigt wird. Eingecheckt sollte das neue Init-System
aber erst, wenn es ein vollwertiger Ersatz für das bisherige
System ist. Dazu fehlt wohl noch einiges an Arbeit, da das
Zapit-Menü wohl nicht mehr so viel Aufmerksamkeit
erfordert, kann ich mich in den nächsten Tagen um diesen
Patch kümmern.

Da es sich beim Init-System um einen integralen Bestandteil
eines Images handelt, sollten nach Fertigstellung des Patches
noch umfangreiche Tests durchgeführt werden, IMHO u.a.
auch mit dietmarw-Testimages.

PS: Und ja, ich bin gegen einen CVS-branch, in dem der Patch
versauert und ebenfalls gegen eine cdk/configure-Option, die
die Makefiles nur unnötig verkompliziert.
dbt
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 19:18

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von dbt »

Ok, das wäre schon mal was, hab ja auch einiges vor und das will ohne diese Sache auch nicht so recht vorwärts gehen und will auch nicht alles immer wieder auf den Kopf stellen müssen.
Wie ich schon wegen der Ide-Menügeschichte angedeutet hatte, habe ich das halt script vom JTG als Vorlage etwas überarbeitet. Evtl könnte man das irgendwie hier mit ranziehen und anpassen.
halt-diff-2009-09-02-22-04-02.patch
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

Dann mache ich folgenden Plan:

1) ich mache zu allem, was bisher in rcS ist, ein init-skript
2) ich bereite das alles so vor, dass es funktioniert
3) allerdings werden bei mir immer alle init-skripte installiert
4) irgendjemand (rhabarber? ;)) macht dann noch die entsprechenden conditionals rein, dass nur die init-skripten installiert werden, die zu den Sachen gehören, die auch mit ./configure enabled wurden.
5) längerfristig könnte man dann noch dafür sorgen, dass z.B. "make flash-openntpd" das openntpd startskript installiert. Dann wären viele conditionals im root/etc/-Pfad weg und es wäre noch schöner (nice to have)

oder sollten wir 4) überspringen und gleich 5) machen?
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

seife hat geschrieben:Dann mache ich folgenden Plan:

1) ich mache zu allem, was bisher in rcS ist, ein init-skript
2) ich bereite das alles so vor, dass es funktioniert
3) allerdings werden bei mir immer alle init-skripte installiert
Das klingt gut, weil vollwertiger Ersatz ;)
Wie stellst Du Dir die Verteilung zwischen Squashfs und jffs2 vor?
Belegt eigentlich jedes Skript einen 64kb-Block im Squashfs?
seife hat geschrieben:4) irgendjemand (rhabarber? ;)) macht dann noch die entsprechenden conditionals rein, dass nur die init-skripten installiert werden, die zu den Sachen gehören, die auch mit ./configure enabled wurden.
Kein Problem.
seife hat geschrieben:5) längerfristig könnte man dann noch dafür sorgen, dass z.B. "make flash-openntpd" das openntpd startskript installiert. Dann wären viele conditionals im root/etc/-Pfad weg und es wäre noch schöner (nice to have)
Daran habe ich auch schon gedacht, ich muss mir mal überlegen,
ob das umsetzbar ist, da unterschiedliche Zielverzeichnisse
berücksichtigt werden müssen.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

rhabarber1848 hat geschrieben:Wie stellst Du Dir die Verteilung zwischen Squashfs und jffs2 vor?
Belegt eigentlich jedes Skript einen 64kb-Block im Squashfs?
Das ist eine Gute Frage (das mit den Blöcken). Belegt jede datei im Squashfs immer einen 64k Block? Das kann ich mir eigentlich kaum vorstellen, weil das wäre ja bei den meisten Anwendungen eine riesige Verschwendung. Muss ich mir mal anschauen.

Wenn wir das geklärt haben, würde ich alles im squashfs (/etc/init.d) installieren und /var/etc/init.d leer lassen. Skripten die der User anpassen will, kann er nach /var/etc/init.d kopieren und dort bearbeiten, die werden dann bevorzugt.

Mit etwas Mehraufwand könnte man dann irgendwann per default ein leeres /var ausliefern, und ein "reset to factory settings" wäre dann auch problemlos machbar.

Wenn wir keine Probleme mit der squashfs-blocksize haben, dann geht es bei den Initskripten vom Platz her um die Grössenordnung wenige kB, also sollte das nicth so dramatisch sein, die teilweise doppelt (im root und var) zu haben.

EDIT: im SquashFS-HOWTO steht, u.a.: "By the 2.x release it was introduced the concept of fragment blocks: an ability to join multiple files smaller than block size into a single block, achieving greater compression ratios". Ich lese das so, dass nicht jede Datei einen ganzen Block benötigt (die 128k-Blöcke, die bei squashfs-3.x jetzt default sind, wären sonst auch sinnlos und generell wäre das für ein embedded-FS etwas grenzwertig).
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

seife hat geschrieben:an ability to join multiple files smaller than block size into a single block
OK, Frage geklärt, Squashfs ist kein Hindernis.
seife hat geschrieben:Wenn wir das geklärt haben, würde ich alles im squashfs (/etc/init.d) installieren und /var/etc/init.d leer lassen. Skripten die der User anpassen will, kann er nach /var/etc/init.d kopieren und dort bearbeiten, die werden dann bevorzugt.
Das ist eine gute Idee.
@dbt: Könnte das auch für init.drives gelten?
Für fstab ist das ja schon jetzt möglich.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

Um ganz ehrlich zu sein: die IDE-Menü-Sache habe ich mir bisher nicht angeschaut.

Ich würde es aber prinzipiell eher so machen, dass das Menü eine Konfigurationsdatei schreibt (/var/etc/ide.conf ?) die dann von einem initskript (init.drives) gelesen wird und ausgewertet wird. Das ist aber nur meine persönliche Meinung. Und ausserdem nur ein "implementation detail".

Am Ende ist es auch egal, was /etc/init.d/01ide aufruft ;)
dbt
Administrator
Beiträge: 2675
Registriert: Donnerstag 28. September 2006, 19:18

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von dbt »

rhabarber1848 hat geschrieben:
seife hat geschrieben:Wenn wir das geklärt haben, würde ich alles im squashfs (/etc/init.d) installieren und /var/etc/init.d leer lassen. Skripten die der User anpassen will, kann er nach /var/etc/init.d kopieren und dort bearbeiten, die werden dann bevorzugt.
rhabarber1848 hat geschrieben: Das ist eine gute Idee.
@dbt: Könnte das auch für init.drives gelten?
Eigentlich war das so vorgesehen. Die Grundversion /etc/init.d/init.drives enthält nur Mountbefehle und muß immer da sein damit die Box überhaupt im jungfräulich geflashtem Zustand bootet. var/etc/init.d/init.drives enthält dagegen alles, also laden der fs-Module, Ide, MMC-Module, mounts und hadparm options. Sollten wir uns dahingehend darauf einigen, dass es für jede notwendige Aufgabe ein Script gibt, dass widerum genau eine bevorzugte /var/etc/init.d/init.machwas -Version statt sich selbst ausführt, wäre es praktisch der Optimalfall und man könnte inti.drives entsprechend aufteilen. Es muss dann nur sichergestellt sein, das die Reihenfolge stimmt bzw. Folgescripte immer erst ausgeführt werden, wenn die Bedingungen für einen erfolgreichen Abschluß der Folgescripte gegeben sind. Wenn man so einen Standard in der Initumgebung hätte, wäre das eine universelle Schnittselle auf die man als Benutzer entweder per Hand oder über GUI recht komfortabel zugreifen kann. In diesem Fall müsste man die GUI nur ensprechend anpassen, damit diese Scripte erzeugt werden.

Praktisch wäre es vorstellbar:
/etc/init.d/init.ide läd standardmäßig die ide,mmc Module und fsTreiber evtl. noch hdparm-Options, mounts werden generell anschließend in /etc/init.d/init.mounts ausgeführt. Durch das umbiegen auf die var/-Versionen greifen dann die Benutzerscripts. So mein Gedanke.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

Warum sind in cdk/root/etc/inittab.newinit die Einträge für vc/[4-6] auskommentiert?
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

seife hat geschrieben:So, habe es nochmals überarbeitet: newinit-2.diff
In FILES_FLASH_RO_EXEC wird K30autofs erwähnt, obwohl
diese Datei nicht Teil des Patches ist.
So wie ich das sehe, soll K30autofs nach S30autofs im Image verlinkt
sein, da das Skript start und stop ausführt. Hast Du schon Überlegungen
angestellt, wie die nötige Verlinkung automatisiert werden kann?
Gleiches würde für tuxmaild, tuxcald, dropbear, lircd und einige
andere daemons gelten.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

Weil ich nicht mal eine shell auf einer virtuellen Konsole benötige, ich kann eh nicht hinschalten ;) Und die belegen IMHO unnötig Speicher.

Das ist aber Geschmackssache.

Verlinkt habe ich die S* und K* einfach lokal. Wie man das in den Makefiles am besten macht, weiss ich noch nicht.

Man könnte auch die init-skripten nur (z.B.) "autofs" nennen und S42autofs und K37autofs sind dann links auf "autofs". So wird es ja auch auf "richtigen" SysV-init Systemen gemacht.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

seife hat geschrieben:Wie man das in den Makefiles am besten macht, weiss ich noch nicht.
Da überlege ich mir gerade was.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

rhabarber1848 hat geschrieben:
seife hat geschrieben:Wie man das in den Makefiles am besten macht, weiss ich noch nicht.
Da überlege ich mir gerade was.
Funktioniert:

Code: Alles auswählen

# ls -la | grep autofs
-rwxr-xr-x 1 root root 1744 21. Sep 11:32 30autofs
lrwxrwxrwx 1 root root    8 21. Sep 11:32 K30autofs -> 30autofs
lrwxrwxrwx 1 root root    8 21. Sep 11:32 S30autofs -> 30autofs
Spricht etwas dagegen, S05drivers und rcS zusammenzufassen?
S05drivers ist kein Start/Stop-Skript, sondern wird nur beim Start
der Dbox benötigt.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

Erste Rohfassung, basierend auf seifes Vorarbeit: EDIT: Patch ist im CVS

Dieser Patch ist eher eine Diskussionsgrundlage denn praxistauglich.
Yadd bootet damit.

- keine gesonderte configure-Option, newinit wird Standard
- S*-Skripte umbenannt, beim Imagebau werden nun Links angelegt, s.o.
- neue Skripte: lircd, dropbear, tuxcald, tuxmaild
- /var-Flashpartition wird nur bei nicht-Yadd-Images gemountet
- neue Datei drivers.hdd, HDD-Code aus drivers dorthin verschoben
(@dbt: Der Name gefällt mir besser als init.drives, kannst Du mit der Datei etwas anfangen?)
- S75gui entfernt, stattdessen wird weiterhin start genutzt, S75gui war nicht als Stop-Skript konzipiert
- Aufruf der Kill-Skripte in umgekehrter Reihenfolge (autofs vor network beenden)
- "K10network stop" wird nur bei nicht-Yadd-Images ausgeführt

To-Do
- IPBox-Support
- fehlende Startskripts nachrüsten (ser2net, djmount, cdkVcInfo, sambaserver, nfsd, ...)
- Skripte nach Kernel 2.4/2.6 trennen und nur die benötigte Version installieren
- Testen, testen, testen
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von seife »

rcS ist bisher total maschinenunabhängig, deswegen habe ich S05drivers extra gemacht.
In sysinit wollte ich nicht die ganzen Treiber laden, weil sysinit nicht im /var/ liegen kann, sysinit macht nur die minimale Initialisierung.

Ausserdem hat man, nachdem sysinit durch ist, schon die serielle Konsole zur Verfügung.
Ein extremer Vorteil, wenn man in /var/etc/init.d ein skript hat, was das Booten verhindert ;)

Insofern: ja, S05drivers ist so gesehen kein init-skript, aber ich finde es trotzdem ok so wie es ist.

(Man könnte es auch in start_neutrino integrieren, aber dann ist das wieder nicht maschinenunabhängig...)
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: "modulare" init-skripte anstatt monolithischer rcS

Beitrag von rhabarber1848 »

seife hat geschrieben:ja, S05drivers ist so gesehen kein init-skript, aber ich finde es trotzdem ok so wie es ist.
Es kollidiert nun mit der automatischen Verlinkung der Initskripte.
Vielleicht bastele ich noch mehr FLASH_EXEC-Variablen oder wir
einigen uns darauf, dass für S0*-Skripte kein K-Skript angelegt wird.