rcS.m4 Customization

[dwilx]

Für Kernel- und BB-Konfiguration wurde doch vor kurzem eine Möglichkeit zur Anpassung eingebaut. Ginge das nicht auch für rcS.m4 zu machen?
http://forum.tuxbox-cvs.sourceforge.net ... =7&t=48443

[Barf]

Ich glaube bzgl neue --with und --enable configure-optionen etwas Vorsicht ist angesagt. Es ist immer besser, konfigurationsmöglichkeiten währen Runtime zu haben. Vgl die Organisation in /etc/init.d auf einem modernen Unix/Linux-System.

Aber was sicherlich nicht schaden wurde ist "customization"-möglichkeit. Man könnte am Anfang ein Userspezifisches Customizationsdatei in m4-format einhängen (falls vorhanden) und Dito am Ende. Details wie in meinem zweiten Beitrag hier.

So eine Lösung wäre sowohl unsichtbar für die, die sich nicht kümmert (keine neue Optionen), als auch sehr kraftvoll für Experten.

Unabhängig von alles Anderes sollte wir Kernelabhängige Auswahl ins m4 verschieben, siehe diesen Beitrag (als auch neulich von jojo vorgeschlagen).

[dwilx]

...Aber was sicherlich nicht schaden wurde ist "customization"-möglichkeit. Man könnte am Anfang ein Userspezifisches Customizationsdatei in m4-format einhängen (falls vorhanden) und Dito am Ende. ...

So eine Lösung wäre sowohl unsichtbar für die, die sich nicht kümmert (keine neue Optionen), als auch sehr kraftvoll für Experten....

Genau sowas wäre völlig ausreichend. Wäre das kurzfristig machbar?

[Barf]

Gesagt, getan.

$customizationdir/rcS_pre.m4 wird am Anfang eingesaugt, nach den Definitionen der Standardmakros, da kann man z.B. Makros (um-)definieren. Falls die Datei wirklich etwas an Output erzeugt, muss "#"/bin/sh" erzeugt werden.

$customizationdir/rcS_post.m4 wird am Ende (bevor rc.local) eingesaugt.

Falls jemanden schlägt vor, m4-Customizations in einem anderen Verzeichniss als $customizationsdir zu verlegen .... ...

Wie man sagt auf englisch, "this gives the user a considerable amount of rope to hang himself".

[dwilx]

Danke! Hättest du auch ein Beispiel zur Hand, um zu sehen wie man das anwenden könnte?

Falls jemanden schlägt vor, m4-Customizations in einem anderen Verzeichniss als $customizationsdir zu verlegen .... ...

Wüsste nicht wo das besser hinpassen sollte

[Barf]

Hättest du auch ein Beispiel zur Hand, um zu sehen wie man das anwenden könnte?

Naja, nicht so schwierig. Es wird einfach includiert, genau so wie #include bei CPP. rcS_post.m4 kann z.B. benutzt werden, um zusätzliche Services (z.B. dropbear) zu starten. Natürlich kann die includierte Dateien auch macros enthalten. In rcS_pre.m4 kann man z.B. die vorige Makros umdefinieren, falls man z.B. insmod auch bei yadd benutzen möchte. Mehr intressante Sachen kann man erreichen, falls man z.B. var, kernel, dev, exportfs als makros definieren... (Mit (define({var},{}) wird /etc und /var/etc das gleiche Verzeichniss ... also rope to hang himself)

Zitat:
Falls jemanden schlägt vor, m4-Customizations in einem anderen Verzeichniss als $customizationsdir zu verlegen .... ...

Wüsste nicht wo das besser hinpassen sollte

Ich dachte nur, falls jemanden "normale" Customizations und m4-Customizations in unterschiedliche Verzeichnisse halten möchte; und eine configure-Option --with-m4-configurationdir haben wollte. Aber dann wird er geteert und gefedert...

[dbt]

Irgenwie läuft hier was quer. Jetzt habe ich aber das Problem, das insmod beim bauen der rcS irgendwie nicht übergeben wird Es wird immer nur die modprobe-Version nach /etc/init.d geschaufelt. Kann das jemand nachvollziehen, habe grad komplett neu gebaut, ist nicht wegzubekommen und sehe auch nicht, ob irgendwelche Änderungen dafür verantwortlich sind.

[Barf]

@dbt:

ändere temporär (zwecks debugging) in ...cdk/root/etc/init.d/Makefile.am die m4-Zeilen so dass du schreibst "echo" bevor m4, und sage Bescheid wie es aussieht (makelog). Es könnte möglicherweise so sein dass customizazionsdir leer ist, und die Kommandozeilenargumente "komisch" geparsed wird.

Möglicherweise auch explitzt customizationsdir explizit setzen, falls es ein Unterschied macht.

[dbt]

Es gibt nur diese Ausgabe:

m4 --define=customizationsdir=/home/dbt/customization rcS.m4

Müsste das nicht Pi mal Daumen so in der Art gemacht werden? Das Target rcS.insmod kann man sich eigentlich sparen, oder sehe ich das falsch?
Jedenfalls bekomme ich so die richtige Version gebaut. Auch die modeprobe-Version mit --enable-kernel26

Code: Alles auswählen

Index: Makefile.am
===================================================================
RCS file: /cvs/tuxbox/cdk/root/etc/init.d/Makefile.am,v
retrieving revision 1.15
diff -u -r1.15 Makefile.am
--- a/Makefile.am	19 Feb 2009 08:56:01 -0000	1.15
+++ b/Makefile.am	1 Mar 2009 22:20:43 -0000
@@ -18,6 +18,8 @@
 
 if KERNEL26
 KERNEL_ARGS=--define=use_kernel_26
+else
+KERNEL_ARGS=--define=insmod
 endif
 
 COMMON_ARGS=--define=customizationsdir=$(customizationsdir) $(KERNEL_ARGS)
@@ -26,6 +28,6 @@
 	m4 $(COMMON_ARGS) $< > $@
 	chmod 755 $@
 
-rcS.insmod: rcS.m4
-	m4 $(COMMON_ARGS) --define=insmod $< > $@
-	chmod 755 $@
+#rcS.insmod: rcS.m4
+#	m4 $(COMMON_ARGS) --define=insmod $< > $@
+#	chmod 755 $@

[dwilx]

Jetzt habe ich komplett gebaut und kann das nachvollziehen. Die rcS.insmod wird nicht erzeugt. Das habe ich erst nicht bemerkt, weil die Datei noch im CDK lag und gewissermaßen nicht gebaut werden musste. Das müsste mal genauer betrachtet werden. Mit dem Patch hier gehts zwar wieder, aber nur in Yadd.

[dbt]

Das hier:

Code: Alles auswählen

...
# Create a telnet greeting
echo "$VENDOR $MODEL - Kernel %r (%t)." > /etc/issue.net
...

kann doch eigentlich auch nicht funktionieren, zumindest nicht in squashfs-Images

[jojo]

wie wäre es denn mit so einem Konstrukt bzgl /etc und mounten von /var?

Code: Alles auswählen

if [ ! -d /var/etc ]; then
   mount /dev/mtdblock/3 /var
fi
mount -o bind /var/etc /etc

Vorteil wäre, das die ganzen Symlinks aus /etc rausfliegen könnten. Auch sollte dann das yadd Problem (unerwünschtes mounten von /dev/mtdblock/3) erledigt sein...

[seife]

gehen bind-mounts auf kernel 2.4?

[jojo]

gehen bind-mounts auf kernel 2.4?

Jo - eben mit 'nem dietmarw Image ausprobiert...