Und da ergibt das Vorgehen von Freetz-NG dann auch tatsächlich einen relevanten Unterschied bei einem System, welches ein "Analogum" zum
systemd verwendet. Während bei AVM der
multid direkt vom
supervisor gestartet wird und unter dieser PID, mit der der Start erfolgte, auch weiterhin läuft (und der steuernde Prozess über ein gesondertes Signal vom erfolgreichen Start in Kenntnis gesetzt wird:
Type=notify), wird bei Freetz-NG der Daemon als Kindsprozess einer Shell aufgerufen (
https://github.com/Freetz-NG/freetz-ng/blob/master/make/pkgs/mod/files/root/etc/init.d/rc.multid) und der vom
supervisor gestartete Prozess ENDET bereits in der Startphase, was üblicherweise den steuernden Prozess dazu veranlassen würde, den Service als "dead" oder "deactivated" anzusehen:
https://www.freedesktop.org/software/systemd/man/systemd.service.html - auch bei AVM sind derartige Praktiken ja zu sehen, dann allerdings i.d.R. i.V.m. einer Angabe
Type=oneshot.
Welche Auswirkungen das jetzt genau auf den Ablauf der Initialisierung des Systems hat, hängt auch davon ab, was AVM aus den Quellen des
systemd für den eigenen
supervisor alles übernommen hat - die Quellen stehen (leider) "nur" unter LGPL-Lizenz und ich habe bisher noch in keinem AVM-Paket gesehen, daß man die eigenen Änderungen DENNOCH veröffentlicht hätte ... das gelingt den Mitarbeitenden bei AVM ja nicht einmal für die Fälle in Gänze, wo sie von einer GPL-Lizenzierung dazu eigentlich VERPFLICHTET wären.
Man weiß - dank der "verschämten Verschwiegenheit" bei AVM - auch nicht genau, ob man dort TATSÄCHLICH den
systemd (
https://github.com/systemd/systemd) als Vorbild/Vorlage für den eigenen
supervisor verwendet hat.
Manches spricht ja (zumindest in meinen Augen) dafür - angefangen bei der Syntax der verwendeten Dateien zur Steuerung.
Andererseits spricht aber DAGEGEN, daß bei AVM dieses Projekt GAR KEINE Erwähnung findet (zumindest nicht in der OSS-Datei für die 07.50 der 7590:
http://osp.avm.de/fritzbox/fritzbox-7590/source-files-FRITZ.Box_7590-grx5-07.50.tar.gz) und das, obwohl doch auch die LGPL-2.1 (und das nicht erst seit gestern) eine entsprechende Kennzeichnung FORDERT:
https://github.com/systemd/systemd/...b05e83c2051f90785d98c646/LICENSE.LGPL2.1#L278
Damit bleibt eine gewisse VERUNSICHERUNG, was AVM da genau implementiert hat und welche Auswirkungen die verschiedenen Angaben in den Konfigurationsdateien am Ende haben - bleibt nur die "Beobachtung" des Verhaltens bei unterschiedlichen Angaben.
Witzig ist aber - zumindest wieder in meinen Augen - auch, daß bei AVM an anderer Stelle sowohl die Quellen für Komponenten, die gar nicht in der veröffentlichten Firmware enthalten sind (z.B.
dropbear, wenn auch in einer vier Jahre alten Version), dabei sind als auch einige Informationen, die vermutlich so gar nicht veröffentlicht werden SOLLTEN, zumindest decken sie ja auch auf, DASS die von AVM veröffentlichten Quellen unvollständig sind, wenn es um den "GU wrapper" geht.
GU Wrapper
----------
The GU wrapper is responsible for the integration of subprojects and should be
the only place containing the implementation needed. To achieve this goal the
GU wrapper uses the hooks and configurations files described above.
The wrapper *MUST* provide `LINUXINCLUDE_AVM_SUBPROJECTS` and
`USERINCLUDE_AVM_SUBPROJECTS` to the Linux Makefile. These variables *MUST*
contain include flags for `include/` and `include/uapi/` folders in each LiSI
compatible subproject, if the respective folder exists. The order of the flags
is unspecified but *SHOULD* be stable.
The wrapper *MUST* generate compatibility header files defined in each
`compat.headers` file. These header files *MUST* rely on the inclusion path
and not on the physical path. Compatibility header files *SHOULD* contain a
deprecation warning, which *MUST NOT* cause a compiler error.
The wrapper *MUST* install subproject header folders into the GU archive and
UAPI header files into the target tree.
The wrapper *MAY* provide `GNUmakefile` and files under `avm/make/generated/`
in the Linux tree. These files *SHOULD* be ignored by the VCS.
Daran ändern (wieder nur nach meiner Ansicht) auch die Vorlagen, die unter
sources/kernel/kgw/makefiles/templates hinzugekommen sind, nichts wirklich - eine Komponente
gu, wie sie in einigen Dateien "referenziert" wird:
Rich (BBCode):
vidar:~/FritzBox/FB7590/GPL_07.50 $ grep -r " gu " sources/kernel/kgw
sources/kernel/kgw/scripts/add-file-helper/check-abi-compat: | xargs -r echo "info: You might want to re-run these GU targets: gu build"
sources/kernel/kgw/scripts/add-file-helper/check-abi-compat: echo "info: To see more details, run: gu env -- xargs -a ${file} ${base}/symvers-check -v" >&2
sources/kernel/kgw/makefiles/defaults.make:kconfig_oldconfig := $(shell gu config --get 'project.kernel.kconfig' 2>/dev/null || echo olddefconfig)
sources/kernel/kgw/makefiles/kbuild.make:# Example: gu config --local --add project.kernel.kconfig-override CONFIG_DEBUG_KMEMLEAK=y
sources/kernel/kgw/makefiles/kbuild.make: ( gu config --quiet --get-regex 'project\.kernel\.kconfig-override' | cut -d= -f2- )
sources/kernel/kgw/doc/debugging.mkd: gu config --set --local build.verbosity trace
sources/kernel/kgw/doc/debugging.mkd:provide kernel && timeout 10s gu build kernel`) helfen in den meisten Fällen
sources/kernel/kgw/doc/debugging.mkd: gu env env LC_ALL=C.UTF-8 make -C ../build V=1
sources/kernel/kgw/doc/debugging.mkd: gu config --add --local gu.project.kernel.kconfig-override CONFIG_MODVERSIONS=y
sources/kernel/kgw/doc/abi-check.mkd: info: You might want to re-run these GU targets: gu build cpunet-main fon_kmods-main vendor-main
sources/kernel/kgw/doc/abi-check.mkd: info: To see more details, run: gu env -- xargs -a .../tmp/check-abi-compat.tmp .../bin/symvers-check -v
vidar:~/FritzBox/FB7590/GPL_07.50 $
findet sich in den AVM-Dateien gar nicht und auch keine Vorlagen/Makefiles, etwas in der Richtung zu erzeugen (zumindest habe ich nichts gefunden, was (für mich) schon mal ein schlechtes Zeichen ist). Die Syntax von
gu-Aufrufen erinnert ja ein wenig an das
git-Projekt - aber ich finde bei einer Internet-Suche keine Hinweise auf Projekte, die einen derartigen Namen verwenden würden.
Aber immerhin hat AVM es mittlerweile dann doch geschafft, ein paar "Werkzeuge" hinzuzufügen, die für einen eigenen Kernel-Build (mit vergleichbarem Ergebnis) unumgänglich sind ... nein, natürlich NICHT die SquashFS-Tools, mit denen man auch bei Version 4 das passende Dateisystem erzeugen könnte, aber die kommen ja vielleicht/hoffentlich auch noch irgendwann.
Jedoch gibt es jetzt (im erwähnten
kgw-Verzeichnis) endlich ein Tool (unter
sources/kernel/kgw/scripts/add-file-helper/link_and_print_symbols.sh i.V.m.
sources/kernel/kgw/scripts/add-file-helper/compute_module_size.pl), mit dem man sich die Module-Tabelle im Konfigurationsbereich SELBST erstellen lassen kann - zumindest das Header-File für eine solche, die dann (wenn man dem Freetz(-NG)-Ablauf beim
make folgen würde) beim Build auch eingebunden werden KÖNNTE ... bei AVM wird sie getrennt übersetzt und das Object-File dann weiterverarbeitet (Zeile 329 im erwähnten Shell-File).
Dort wird dann jetzt in Perl die Ausgabe des
readelf-Tools zerlegt, um daraus dann die Angaben für die vier Zahlen zu erhalten, die in der Module-Tabelle für die LKM hinterlegt sind. Das läuft dann halt über alle LKM im Verzeichnis
lib (für den neuen Kernel - gesucht werden sie mittels
find) und im Shell-Skript wird dann sogar (mittels
dd 
) noch der betreffende Bereich im (noch ungepackten) Kernel ersetzt - das macht dann das bisher dafür erforderliche
avm_kernel_config (
https://github.com/PeterPawn/YourFritz/tree/main/avm_kernel_config bzw. dessen Kopie in Freetz/Freetz-NG) obsolet. Allerdings erfordert es wieder Änderungen beim Kernel-Build ... das gehört jetzt dort in die "Nachbereitung" vor dem Packen des eigenen Kernels (weil erst einmal die Module vorliegen müssen), wo ich persönlich mein
avm_kernel_config ja auch schon immer am liebsten angesiedelt gesehen hätte.
Warten wir mal ab, ob/wie das
@cuma/@fda77 lösen wird ...
