Skip to content

Commit

Permalink
freetz-ng: fix time of assignment for GNU_HOST_NAME variable
Browse files Browse the repository at this point in the history
  • Loading branch information
@PeterPawn
PeterPawn committed Jun 4, 2022
1 parent 978763f commit b8ec32d
Showing 1 changed file with 15 additions and 0 deletions.
15 changes: 15 additions & 0 deletions Makefile
View file
Expand Up @@ -279,6 +279,21 @@ export VERBOSE
include $(INCLUDE_DIR)/Makefile/echo.mk
include $(INCLUDE_DIR)/Makefile/macros.mk

HOSTCC:=gcc
HOST_ARCH:=$(shell $(HOSTCC) -dumpmachine | sed -e s'/-.*//' \
-e 's/sparc.*/sparc/' \
-e 's/arm.*/arm/g' \
-e 's/m68k.*/m68k/' \
-e 's/ppc/powerpc/g' \
-e 's/v850.*/v850/g' \
-e 's/sh[234]/sh/' \
-e 's/mips-.*/mips/' \
-e 's/mipsel-.*/mipsel/' \
-e 's/cris.*/cris/' \
-e 's/i[3-9]86/i386/' \
)
GNU_HOST_NAME:=$(HOST_ARCH)-pc-linux-gnu

include $(TOOLS_DIR)/make/Makefile.in
include $(call sorted-wildcard,$(TOOLS_DIR)/make/*/*.mk)

Expand Down

27 comments on commit b8ec32d

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Der Commit allein würde ein Clone vom Code in make/Makefile.in erstellen. Man braucht die Variablen aber nur 1x.
Der ursprüngliche Fehler war dass GNU_HOST_NAME in tools, toolchain und packages verwendet wird, aber in packages angelegt wurde. Das hat vorher nur durch Zufall/Verwendungsweise funktioniert. "make -d" ist nett um sich anzusehen.

@PeterPawn
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mein Commit hatte nur das eine Ziel ... einen Workaround für das bestehende Problem, bei dem so wenig wie möglich an den ursprünglichen Daten geändert wird. Da spielte eher die Frage, daß ich nur EINE Datei ändern wollte, mit, als irgendwelche Überlegungen, wie bzw. wo man das nun am besten unterbringen könnte.

Ich habe gar nicht erst nachgesehen, ob/wo/wie die Variable $(PKG)_CONFIGURE_OPTIONS erstmals definiert wird für Makefiles mit TOOLS_INIT ... aber da ja offensichtlich(!) kein Wert für $(GNU_HOST_NAME) gesetzt war, wenn die betroffenen Pakete konfiguriert wurden, KANN das eigentlich nur irgendwo als "simply expanded variable" definiert/genutzt sein.

Wäre das hingegen eine "recursively expanded variable", wäre es auch egal, wenn $(GNU_HOST_NAME) erst später seinen Wert erhält ... denn dann wird dieser Wert eben erst bei der Verwendung der Variablen $(PKG)_CONFIGURE_OPTIONS ausgewertet. Ich vermute/hoffe mal, das ist bei den Definitionen für die INIT-Makros aus dem "originalen Freetz" der Fall (zumindest ging ich bisher davon aus) und dann wäre das eben nicht "nur zufällig".

Ich empfehle hinsichtlich der Unterschiede zwischen diesen Variablen-Typen und der Art und Weise ihrer Definition bzw. der Behandlung beim Anfügen von Text die Lektüre des Manuals für GNU make: https://www.gnu.org/software/make/manual/make.html#Flavors - speziell die Kapitel 6.2, 6.5 und 6.6.

Denn das könnte durchaus eine Alternative sein, daß man diese Variablen als "recursively expanded" definiert ... da man keinen weiteren Einfluß auf die Reihenfolge beim Einbinden von anderen Makefiles hat (die werden durch das $(sort ...) ja nach Namen sortiert eingefügt), kann man ansonsten in einem Paket keine Bezüge auf den Inhalt der Variablen eines "fremden" Makefiles verwenden (wenn das erst "später" eingebunden wird) - z.B. wenn man zwei Pakete hat, von denen eines nur eine Library erstellt, die von einem anderen gelinkt werden, aber ansonsten nicht installiert werden soll, nicht mal im "staging"-Bereich.

Ich hatte das Problem mal mit meinem "decrypt-fritzos-cfg" (bzw. dem Original "decoder"), als es um die Frage ging, ob/wie ich komplikationslos beim Build im Rahmen von Freetz an die libnettle als Paket kommen könnte - die wird nur zum statischen Linken benötigt und es gibt keinen Grund, die danach noch (zusätzlich) irgendwo zu installieren.

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 5, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jo, bin Anfänger mit Makefiles. In der makros.mk sind wirklich nur defines, die dort wo sie waren zu spät für "tools" waren. Eigentlich genau wie die Variable
Warum willst du eine lib denn nicht im staging haben? Mit DEPENDS in der .mk landet dir dort, kommt aber nur ins .image wenn sie auch in der .in selectiert wird. Das machen auch Packages die statisch gebaut werden so. Das ist eigentlich keine Sonderfall.
OT: Freetz-NG@c4370f5

@PeterPawn
Copy link
Owner Author

@PeterPawn PeterPawn commented on b8ec32d Jun 6, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ich rede von "durchgängigen" Entscheidungen für eine bestimmte Architektur (und dann natürlich auch von durchgehender Implementierung gemäß solcher Entscheidungen). Wenn ich die OPTION haben will, daß ein Paket auf die Werte von (make-)Variablen in einem anderen Paket zugreifen kann, dann MUSS ich (beim derzeitigen Aufbau in Freetz(-NG)) die durch Makros definierten Variablen für ein Paket als "recursively expanded" definieren, da ansonsten eben der Wert, der zum Zeitpunkt der (ersten) Zuweisung vorhanden war, in das Ziel übernommen wird.

Warum so eine "Kooperation" über mehrere Pakete sinnvoll sein kann, habe ich versucht, mit meinem Beispiel zu erklären ... sicherlich KANN man das alles auch irgendwie anders lösen, es erhöht aber die Transparenz der Vorgänge beim Build nicht gerade. Und spätestens dann, wenn man z.B. eine andere Konfiguration einer Library verwenden will (oder gar muß), für die es bereits ein Freetz-Paket gibt, macht es sogar dann schon Probleme, wenn man die nur im Staging-Bereich installiert.

Andererseits gibt/gab es diese "Makefile-übergreifende Verwendung" von Variablen-Namen auch schon in Freetz - das hier ist nur ein weiteres Beispiel für einen solchen Fall: https://github.com/Freetz-NG/freetz-ng/blob/82a75cde808a92a66c58383f9266a65ea3b60bdc/tools/make/mpc-host/mpc-host.mk#L19 und auch hier macht das nach Deinen Änderungen Späne, weil eben auch mpc-host VOR mpfr-host beim include verarbeitet wird (die Zeile darüber, die mit der gmp-Referenz, funktioniert wieder (und hier ist "zufällig" dann auch die richtige Wortwahl), weil das eben bei der Sortierung VOR mpc-... kommt) und die Variable ${MPFR_HOST_DESTDIR} (oder meinetwegen auch mit runden Klammern, das ist dem make egal) zu dem Zeitpunkt, wo mpc-host.mk eingelesen (und verarbeitet) wird, noch gar nicht gesetzt ist.

@PeterPawn
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wenn sich das Thema hier fortsetzen sollte, ist es sicherlich schlauer, das nicht gerade in den Kommentaren für einen Commit zu machen, der gar nicht mehr in irgendeinem Branch enthalten ist ... sonst fehlt dem am Ende nach einem prune, bei dem der Commit entfernt wird, auch noch der Anker. Ich weiß nicht, was GitHub dann macht, wenn der betreffende Commit nicht länger existiert ... Dein Link in irgendeinem Commit-Text, der auf das IPPF zeigte, stimmt inzwischen jedenfalls nicht mehr, weil ich (unabsichtlich - da ich neue Benachrichtigungen wollte) den ursprünglichen Beitrag in einen neuen kopiert und ergänzt und danach ersteren gelöscht hatte.

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Github macht komische Dinge mit commits, zb ist dieser deinige nie in diesem repo gewesen: Freetz@b8ec32d
Daher glaube ich nicht dass dieser kommentierte Commit je verschwinden wird und die Kommentare dazu. Aber kannst gern sonstwo schreiben
Der link zum IPPF ist schon extra ohne title, bei neuem kann ich aber nichts machen, wenn du willst füg dem commit der den referenziert einen Kommentar mit neuer url hinzu

https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yf-akcarea-host/yf-akcarea-host.mk#L18=
und
https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/dtc-host/dtc-host.mk#L6=
geht dann nur mit alphabetischem Glück (je nach Spracheinstellung)

Wie man das und mpc-/mpfr-/gmp-host am besten löst weiss ich noch nicht... vielleicht ersetzt man $(PKG)_ einfach durch den wirklichen Namen, also zb DTC_HOST_

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Genauer betrachtet...
In https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/mpc-host/mpc-host.mk
gibt es

  • MPC_HOST_DESTDIR
  • GMP_HOST_DESTDIR
  • MPFR_HOST_DESTDIR

Die alle evtl nicht gesetzt sind und $(HOST_TOOLS_DIR) sein sollten ... das könnte man auch direkt verwenden

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-> Freetz-NG@30f2978

Die _HOST_BINARY der 3 libs werden jetzt nur noch von kernel+target gcc verwendet, die toolchain/ werden nach tools/ in der /Makefile included, passt.
Scheinbar sind aber noch diese 3 Variablen abhanden gekommen: https://github.com/Freetz-NG/freetz-ng/blob/master/toolchain/make/target/gcc/gcc.mk#L64=

nach Deinen Änderungen Späne

Ich muss sagen dass ich überrascht bin wie wenige das sind! :D

@PeterPawn
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Warum einfach, wenn man's auch kompliziert machen kann? Warum definierst Du die Variable $(PKG)_CONFIGURE_OPTIONS nicht einfach in Deinem neuen Makro so, daß sie (später, wenn da weiterer Text hinzugefügt wurde im jeweiligen mk-File) rekursiv aufgelöst wird? Genau darauf wollte ich ja schon seit meiner ersten Antwort oben hinaus ... wenn auch eher indirekt und nur in Form eines "Vorschlags", was Du Dir ansehen solltest, wenn Du diese Änderungen, so wie man sie jetzt sieht (ob man die Intention dahinter richtig interpretiert, steht auf einem ganz anderen Blatt, denn das muß man sich ja nach wie vor selbst "zusammenreimen"), auch durchhalten willst.

Denn wenn die drei von Dir "aufgezählten" Variablen eben erst dann auch aufgelöst WERDEN, wenn sie benötigt werden, ist das ganze "Problem" nur noch heiße Luft (weil es dann keine Rolle mehr spielt, in welcher Reihenfolge die mk-Files eingelesen werden) und solange Du nicht auch noch planst, das bisher verwendete GNU make durch irgendetwas anderes zu ersetzen (das Konzept der "simply expanded variables" ist ja nicht im POSIX-Standard spezifiziert), spricht ja auch nichts dagegen, wenn man die Makefile-Syntax so wählt, daß man mit dem GNU-Tool das beabsichtigte Ziel erreicht.

Es führen halt viele Wege nach Rom und u.U. ist sogar die "second expansion" (Kapitel 3.9 des make-Manuals) eine Option (auch wenn ich das persönlich so nicht angehen würde) ... aber gleichzeitig hast Du noch weitere Fehler in Deinen neuen Makros, wie man an dem Log-Auszug sehen kann, den ich im IPPF gezeigt habe: https://www.ip-phone-forum.de/threads/makefile-fehler-mit-rsblsh1-bei-freetz-ng-19625m-c4080df12-master-2022-06-02.313214/post-2479055 ... falls Du da irgendwo tatsächlich ein kill aufrufen willst, sollte das schon (nach ggf. sogar rekursiver Auflösung) eine entsprechende PID mit bekommen - zumindest ein einzelnes Dollarzeichen ist da ja auch zu sehen, was schon mal für ein "Verdoppeln" in der Makro-Definition spricht, während "der Leser" aber trotzdem raten muß, was das eigentlich soll und ob das fehlende F im Namen der Variablen REETZ_VERBOSITY_LEVEL (in conf_cmd()) jetzt "Absicht" ist (und ein Q&D-Weg, das zu (de-)aktivieren) oder doch nur ein simpler Schreibfehler, der aber nicht aufgefallen ist, weil das nie getestet wurde.

Bei der Syntax von Makefiles kann man aber leicht Fehler machen (gerade die korrekte Anzahl von Dollarzeichen ist ähnlich anspruchsvoll wie bei der Verwendung von "inline files" in Shell) und daher kommt man nach solchen Änderungen um einen (gründlichen) Test nur herum, wenn man sich nicht daran stört, daß die eigenen "Benutzer" dann eben nach solchen Änderungen immer erst mal "bangen" müssen, ob dabei nicht irgendwelche neuen Fehler hinzugekommen sind. Da auch weiterhin "version bumps" für neue Versionen der Software in den Paketen und solche Änderungen an der Struktur von Freetz-NG bunt gemischt in demselben Branch auftauchen, bleibt bei solchen Problemen den Benutzern auch nichts anderes, als entweder mit einem älteren Software-Stand ihre Pakete zu bauen oder zu warten, bis das Problem irgendwo aufgefallen, beschrieben, untersucht und eventuell sogar gefixt wurde. Alles das wäre gar kein Problem, wenn man das sauber trennen und in entsprechenden Feature-Branches veröffentlichen würde ... aber ich klinge wieder wie die kaputte Schallplatte und ich wollte mich ja eigentlich aus Freetz-NG heraushalten. Das Problem habe ich mir auch nur angesehen, weil es im IPPF "gemeldet" wurde und nicht in einer GH-Issue oder -Diskussion.

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Da warst du zu langsam / hast zu viel geschrieben ;-)

falls Du da irgendwo tatsächlich ein kill aufrufen willst

Ja, mich nerven die "geht nicht, Error 1" posts. Ich bin gespannt wie die sich nun ändern. Es wird jedenfalls nur noch "Beendet" angezeigt. Den Fehler muss man (wie vorher) weiter oben suchen. Da fällt §4 leicht: https://github.com/Freetz-NG/freetz-ng/blob/master/.github/ISSUE_TEMPLATE/1-bug_report.md

das fehlende F im Namen der Variablen REETZ_VERBOSITY_LEVEL

Sollte seit gestern behoben sein: Freetz-NG@8953390

Dieses verdoppeln hängt davon ab ob das von SUBMAKE oder CONFIGURE aufgerufen wird (war schon immer so): https://github.com/Freetz-NG/freetz-ng/blob/master/make/Makefile.in#L7=

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 7, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

solange Du nicht auch noch planst, das bisher verwendete GNU make durch irgendetwas anderes zu ersetzen

Ne, aber cmake hätte ich gerne in der toolchain... aber das mit der site-file ist aber etwas kompliziert. Mir fallen auch max 2 programme eine die das evtl benötigen (getdns, evtl ne lib von neuerem rrdtool)

Wo wir bei gerne-hätten sind: Ich hätte gerne die ganzen .mk-files in so einem Baum

  • make/packages
  • make/libraries
  • make/kernel
  • make/tools
  • make/toolchain

Ich finde die aktuelle "Verteilung" komisch. Aber erst nach dem nächsten TAG (größere änderungen (zb "makros") -> fehlerbehebung -> tag -> ...)

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Freetz-NG@da05d4a

Scheinbar sind aber noch diese 3 Variablen abhanden gekommen

Doch nicht, die kommen von den target-libs, zb https://github.com/Freetz-NG/freetz-ng/blob/master/make/libs/gmp/gmp.mk#L10=

Warum definierst Du die Variable $(PKG)_CONFIGURE_OPTIONS nicht einfach in Deinem neuen Makro so, daß ...

Ich hab diese ganzen makros für die tools einfach von den packages übernommen bzw für tools teilweise angepasst. Das hätte dann auch Auswirkungen auf die ganzen Packages da sie von beiden genutzt werden

@PeterPawn
Copy link
Owner Author

@PeterPawn PeterPawn commented on b8ec32d Jun 7, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Das wäre alles gar nicht nötig (vor allem wären die Makros für Pakete und Bibliotheken gar nicht betroffen, wenn man das nur in TOOLS_INIT machen würde), wenn man's denn richtig verstanden hat. Vielleicht helfen ja auch noch die Kapitel unterhalb von 3. im make-Manual - da ist dann noch einmal EXPLIZIT beschrieben, wie so ein Makefile eingelesen und verarbeitet wird und was man beim Auflösen von Variablen hinsichtlich des passenden Zeitpunkts beachten muß.

Auch wenn ich mich raushalten wollte/will ... das, was Du da gerade alles geändert hast, ist (a) unnötig (wenn man die gemachten Fehler hinsichtlich "simple vs. recursive" korrigiert) und (b) VERRINGERT die Übersichtlichkeit eher.

Für Libraries und Binärpakete für die Box ist es nicht mal wirklich relevant, daß die Variablen auch dort rekursiv aufgelöst werden ... die haben schließlich alle ihr (gemeinsames) Environment für configure, das in TARGET_CONFIGURE... definiert ist (inkl. der Angaben zu host, build und target) und da dort auch die Pfade für Include-Files und (staged) Libraries beim Aufruf von configure richtig gesetzt sind, funktioniert(e) das bisher in Freetz (und das seit Jahren) eigentlich ganz gut.

Das Durcheinander ist erst dadurch entstanden, daß nach Deinen Änderungen die Variablen (und das eigentlich auch nur für die "host tools") zum falschen Zeitpunkt aufgelöst werden: https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html#Reading-Makefiles - Kapitel 3.7 und 3.8. Wenn man verstanden hat, wie das funktioniert bzw. abläuft, kann man es auch so umsetzen, daß es die bisher sichtbaren 6 Commits von heute gar nicht gebraucht hätte.

Die Reihenfolge für das "Einbinden" anhand von einem numerischen Präfix ist genauso unsinnig (vielleicht noch dazu geeignet, dem "Leser" eine Reihenfolge näher zu bringen), wie das Sortieren der Pakete nach ihren (alphabetischen) Namen - schließlich dient make ja genau dafür, daß man solche Abhängigkeiten nur einmal "ausformuliert" (genau das ist ja das jeweilige Makefile) und nicht ständig wieder "überarbeiten" muß.

Eine einzige zusätzliche Zeile in der Definition von TOOLS_INIT hätte das (für die Variable $(PKG)_CONFIGURE_OPTIONS) ganz einfach lösen können. Dann wäre deren Auflösung "verzögert" erfolgt ("deferred" - siehe Manual) und dann wären zu diesem Zeitpunkt auch die Variablen mit den Zielverzeichnissen für die drei vom gcc benötigten Pakete sauber gesetzt gewesen. Ich verstehe ohnehin nicht, warum Du die ganzen "initialen Definitionen" der Variablen in den Makros alle als "simply expanded" definiert hast (also MIT Doppelpunkt(en)) - auch wenn das bisher in Freetz so gewesen sein sollte (ich habe gar nicht nachgesehen), ist das ja weder logisch nachvollziehbar, noch notwendig ... ja, es wäre erst dafür verantwortlich, daß solche Probleme, wie die mit den heutigen Commits behobenen, überhaupt aufkommen können.

Ich sähe jedenfalls keinen guten(!) Grund, warum man die nicht als rekursiv aufgelöste Variablen verwenden sollte - solange nicht dieselbe Variable mehrfach (mit unterschiedlichem Inhalt) zugewiesen wird (was durch den Bezug auf $(PKG)... bei den meisten ja vermieden wird), spielt es gar keine Rolle, wann die Auflösung erfolgt ... ja, die verzögerte Auflösung sorgt erst dafür, daß die Reihenfolge(!) von Definitionen und Zuweisungen keine Rolle mehr spielt; nur auf den korrekten "Typ" einer solchen Variablen (der eben bei der ERSTEN Verwendung - egal ob bei einer Zuweisung oder als Referenz - festgelegt wird) muß man dann eben achten.

Ich gehe mal davon aus, daß den bei Freetz früher Beteiligten die Unterschiede bei Variablen-Typen (im make) und die jeweiligen Zeitpunkte der Auswertung/Zuweisung durchaus geläufig waren ... diese Funktionsweise von make ist ja auch der Grund, warum die Variablen in einem "recipe" (also in den Anweisungen innerhalb einer Regel bzw. eines Ziels, nicht in der Definition einer/eines solchen) eben nicht mit dem $(PKG)-Präfix arbeiten können (der ist zum Zeitpunkt der Ausführung dieser Anweisungen nicht bzw. falsch gesetzt) und stattdessen da jeweils selbst der Paketname substituiert werden muß.

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 7, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Das wäre alles gar nicht nötig ... wenn man's denn richtig verstanden hat

Da bin ich mir nicht sicher. Die offizielle make doku finde ich recht sperrig zum lesen!

Die Reihenfolge für das "Einbinden" anhand von einem numerischen Präfix ist genauso unsinnig (vielleicht noch dazu geeignet, dem "Leser" eine Reihenfolge näher zu bringen)

genau, einer erinnerung für mich

Eine einzige zusätzliche Zeile in der Definition von TOOLS_INIT hätte das (für die Variable $(PKG)_CONFIGURE_OPTIONS) ganz einfach lösen können.

Weiss ich nicht (ich glaub dir einfach mal), finde es so aber ganz okay, da die Pfade egal sind, bzw alle tools-libs in 1 Verzeichnis landen. Bei packages hat ja auch nicht jede Lib ein eigenes Verzeichnis, sondern 1 für alle Libs

Ich verstehe ohnehin nicht, warum Du die ganzen "initialen Definitionen" der Variablen in den Makros alle als ..

Das für tools ist einfach analog zu packages/libs, ich wollte das Rechteckt nicht neu erfinden! Wenn man das ändern wollte, sollte man es für alles
Freetz-NG@3294a2f geht fast nur um die defines

funktioniert(e) das bisher in Freetz (und das seit Jahren) eigentlich ganz gut.

Ich hoffe dass es das noch immer macht!

Für Libraries und Binärpakete für die Box ist es nicht mal wirklich relevant ... die haben schließlich alle ihr (gemeinsames) Environment für configure

Tools nun auch https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/Makefile.in#L62=
Die haben nun ebenso gewisse features "geerbt" wie pre/post cmds, patch-apply, dl-mirror, dependencies usw

Was noch nicht ganz passt "DTC_HOST_LIBFDT_DIR" in yf-akcarea-host. Funktionier allerdings. Wenn man es wie in scons-host machen wollte würde man einfach die Pfade hardcodieren...
Weshlab wird von dtc-host die "libfdt.a" und was sonst noch nötig ist "installiert"?

@PeterPawn
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weshlab wird von dtc-host die "libfdt.a" und was sonst noch nötig ist "installiert"?

Keine Ahnung ... ist nicht von mir so gelöst, sondern von @er13. Ich hätte es auch ohne Installation im Staging-Bereich gelöst (und auch ohne Build zum falschen Zeitpunkt, sondern erst dann, wenn/falls das Tool tatsächlich benötigt wird) - also "nicht mein Tisch".

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ich hab ein "nicht" vergessen. Richtig:
Weshlab wird von dtc-host die "libfdt.a" und was sonst noch nötig ist NICHT "installiert"?
Ich fände das logischer und auch einfacher umzusetzen

@PeterPawn
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ich fände das logischer und auch einfacher umzusetzen

Auf dem Build-Host? Denk' mal noch etwas darauf herum und stelle Dir z.B. die Frage, WO das dann installiert werden sollte. Kleiner Tipp meinerseits: NICHT außerhalb des Freetz-Verzeichnisses ... ja, sogar innerhalb eines der Verzeichnisse, die bei einem *clean-Target auch entsorgt werden.

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kleiner Tipp meinerseits: NICHT außerhalb des Freetz-Verzeichnisses

Ich bin zwar Anfänger aber SO doof auch nunmal nicht... In tools/build/ natürlich, wo auch andere include und .a installiert werden.. dort würden sie auch automatisch ins precompiled package eingebunden.
Also wie die anderen in tools. So spezielle Ausnahmen machen immer mehr Aufwand

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-> 046530b und bddfc45

@PeterPawn
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wenn Du nun auch noch darauf verzichtest, die Größe des Konfigurationsbereichs im Kernel schon beim fwdu zu ermitteln, nur damit mit diesem Wert dann eine Property (FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE) in generate.sh erzeugt werden kann, die genau ein einziges Mal referenziert wird (nämlich in kernel.mk: https://github.com/Freetz-NG/freetz-ng/blob/503aa3dda4a9ff16290f4fe34419146e9bcd7b70/make/linux/kernel.mk#L207) und das auch noch an einer Stelle, wo vielleicht zwei von 100 Benutzern jemals vorbei kommen (nämlich beim Linken eines EIGENEN Kernels), dann brauchen auch nur noch diese zwei Benutzer jemals die Schritte auszuführen, die mit avm_kernel_config verbunden sind - nimmt man das also (meinetwegen als Batch-File, damit das "recipe" nicht so lang wird) auch erst an dieser Stelle ins Rezept auf, kommen 98 von 100 Benutzern gar nicht mehr in die Verlegenheit, dieses Programm zu benötigen und somit entfällt dann auch die damit ansonsten verbundene Notwendigkeit, noch die 32-Bit-Unterstützung auf dem Build-Host vorzuhalten (das haben wir ja auch oft genug "besprochen").

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 8, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Es werden mittlerweile viel weniger tools gebaut (wenn man sie selbst baut) da es mehr Abhängigkeiten gibt: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/Makefile.in#L24=
Hier besonders zu beachten "FREETZ_AVM_KERNEL_CONFIG_AREA_KNOWN"

FREETZ_AVM_PROP_KERNEL_CONFIG_AREA_SIZE_0 sollte also weiterhin bekannt sein um das ganze zu deaktivieren, eine "0" steht für Erkennung "geht net" (du weisst ja)
Für die aktuellen v4 Kernel dürfte das immer 0 sein (hoffe ich, nicht nachgeschaut)
Dh das ganze läuft "überflüssig" nur wenn man nur Kernel-MODULE baut bei einem v3 Kernel dessen AKC bekannt ist ...

Wenn an FREETZ_AVM_KERNEL_CONFIG_AREA_KNOWN um "min 1 modul aktiviert" (so eine option sollte es bereits geben) erweitert, müsste man aber bei replace-kernel an/aus-Änderung eine rebuild-check-rule haben die den ganzen Kernel+Module neubaut. Das wird viel compilier-Zeit brauchen. Ich glaube das ist nicht so sinvoll um das relativ kurze bauen des tools zu vermeiden.
Höchstens für die aarch64 Nutzer

Btw, gab es nicht noch ein 2. Stelle die 32-bit erforderte? Oder war das nur hier?

@PeterPawn
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

müsste man aber bei replace-kernel an/aus-Änderung eine rebuild-check-rule haben die den ganzen Kernel+Module neubaut

Braucht man die nicht ohnehin? Wenn ich zwischen dem AVM-Kernel und einem eigenen wechseln will, muß ich halt den eigenen Kernel auch bauen und wenn ich den AVM-Kernel verwenden will, müssen dessen Dateien (in erster Linie die kernel-abhängigen Header-Files) vorhanden sein, wenn ich die Toolchain (und einige Pakete) übersetze.

Zusätzlich gibt es Modelle, wo IMMER die Größe 0 herauskommen wird, weil diese Boxen gar keinen Konfigurationsbereich im Kernel haben (auch dann nicht, wenn sie einen Kernel > 3.10 benutzen), weil diese Daten in einem FDT-Abschnitt stehen (bei den Modellen mit FIT-Images) - für die wird das dann (wenn ich's nicht falsch gesehen habe) aber bei JEDEM Entpacken der Firmware aufs Neue versucht, oder? Wenn ..._SIZE_0 gesetzt ist (was bei nicht wenigen Images in config/.img/... der Fall ist) und die Kernelversion > 3.10 ist, wird ..._KNOWN nicht gesetzt in der config/avm/kernel.in und in der Folge wird yf-ackarea-host zu TOOLS_CONDITIONAL hinzugefügt, weil das im else-Zweig Deines if steht.

Außerdem hast Du da (glaube ich jedenfalls, ich habe nicht nachgesehen, sondern das nur in irgendeinem grep gesehen) irgendeinen Pfad arch/mips/irgendwas in den Makefiles stehen ... das mag ja (früher mal) gültig gewesen sein, solange das max. GRX5-Boxen waren, aber bei den neueren Modellen (wo aber bisher REPLACE_KERNEL i.d.R. kein Thema ist und vielleicht ist das daher bisher auch nicht aufgefallen) kann auch das ganz schnell auf die Nase fallen, wenn die Architektur-Verzeichnisse gar nicht (mehr) existieren (speziell das für mips) oder andere (architekturabhängige) Include-Files aus dem richtigen(!) Verzeichnis eingebunden werden müssen.

Soweit ich das sehe, haben/brauchen auch viele neue Kernel (mit 4.x und größer) durchaus auch weiterhin einen passenden Konfigurationsbereich ... denn selbst wenn der FDT mit der Hardware-Beschreibung vom Bootloader kommen sollte, sind die anderen Informationen, die da noch enthalten sind (speziell die "Modul-Tabelle", in der die Größen der zu reservierenden Speicherbereiche für die LKM stehen), auch weiterhin notwendig - sonst können die von AVM geänderten Speicherzuordnungsfunktionen für den Kernel keinen "non-paged memory" für die Teile des LKM-Codes zuordnen, die nicht ausgelagert werden dürfen, damit in der yield()-Behandlung keine Paging-Exceptions auftreten können.

WENN man also bei den neueren Modellen irgendwann mal REPLACE_KERNEL machen will, dann braucht man auch automatisch weiterhin das Erzeugen der Modul-Tabelle und die steht nun mal im Konfigurationsbereich (immer noch, soweit ich weiß) ... schließlich stammen die konkreten Angaben dazu aus den LKM, die zum jeweiligen Kernel gehören und solange AVM diese Angaben nicht irgendwann beim Systemstart aus dem Dateisystem durch die Suche nach vorhandenen LKM holt, müssen diese Daten ja irgendwoanders ihren Ursprung haben. Da aber selbst bei den neuesten Modellen mit FIT-Image diese Daten NICHT dynamisch zur Laufzeit zusammengesucht werden (schließlich stehen sie auch dort noch im FDT, der zum Kernel gehört), müssen sie auch bei den Modellen OHNE FIT-Image irgendwo hinterlegt sein und das kann/wird eben auch weiterhin der Konfigurationsbereich im Kernel sein.

Das wäre jedenfalls mein "Kenntnisstand", wobei ich dazu tatsächlich NICHT weiter recherchiert habe, als ich zwischendrin mal einige neuere Boxen per SSH untersuchen konnte. Nur bei den Geräten mit FIT-Image stehen die Daten dann stattdessen in den FDT-Schnipseln, die jeweils zur Konfiguration eines Kernels gehören (als Abschnitt avm-fw-info). Bei allen Modellen, die kein FIT-Image verwenden, braucht man daher (wie gesagt, soweit ich das im Moment weiß) auch weiterhin das Extrahieren des Bereichs aus dem AVM-Kernel, wenn man seinen eigenen verwenden will.

Aber ich rate mal ganz wild und denke, daß der vorhandene Code für avm_kernel_config bei den ARM-Modellen nicht richtig funktioniert (ich habe nicht geprüft, ob da eines oder mehrere von denen auch eine Size > 0 hat nach Deinem generate.sh), unter Umständen sogar deshalb, weil er mit der anderen "byte order" (LE statt BE bei MIPS) nicht korrekt umgeht (vielleicht sind's aber tatsächlich auch nur die Pfade, weil eben unterhalb von arch/mips/... ggf. andere Header-Files liegen, die für BE-Architektur gültig sind und es hilft vielleicht schon, wenn man das einfach bei ARM-Boxen auch im richtigen(!) Verzeichnis bauen läßt (alles nur Spekulation, nichts getestet oder genauer geprüft von mir).

Vielleicht liegt es aber auch daran, daß man beim "externen Blick" auf den Kernel eben keine Angabe aus kallsyms hat (außer man entpackt diese Infos auch noch), um den Konfigurationsbereich zu finden und solange der nicht wenigstens irgendeinen (ggf. auch unbenutzten) FDT enthält, findet man den auch nicht anhand der (FDT-)Signatur und genau danach wird gesucht und dann "zurück gerechnet".

Andererseits kann man selbst im Kernel einer 07.39-Labor für die 7590 noch den Konfigurationsbereich ausfindig machen (er existiert also auch dort noch), während Deine generierten Dateien in config/.img/... auch dafür noch auf ..._SIZE_0 bestehen (Beispiel: https://github.com/Freetz-NG/freetz-ng/blob/899d9bb66d4325670f5c3ff215be750d8d99969a/config/.img/7590--07_2X.in#L67 - auch wenn's keine 07.39 ist) und das dürfte für so manches Modell nicht stimmen.

Vielleicht verstehe ich ja aber den Sinn dieser Dateien (oder auch der Variablen ..._SIZE_X) nur nicht richtig ... warum genau wird da in generate.sh nach der Größe gesucht (https://github.com/Freetz-NG/freetz-ng/blob/899d9bb66d4325670f5c3ff215be750d8d99969a/config/generate_img.sh#L894), wenn in der generierten Datei nicht die RICHTIGE Größe für das Modell (und die Firmware-Version) stehen soll?

Außerdem verstehe ich gar nicht, warum nach Deiner Ansicht das Ein- oder Ausschalten von REPLACE_KERNEL eine (direkte) Auswirkung auf das Bauen von avm_kernel_config (als "host tool", was ohnehin nicht stimmt) haben sollte ... wenn die Konfigurationseinstellungen für den Build des Kernels tatsächlich dessen Linken bewirken sollten (nur für zusätzliche eigene Module braucht's den Konfigurationsbereich ebenfalls nicht), dann reicht eine passende Abhängigkeit dieser Regel zum Linken des Kernels bereits aus, wo man nur avm_kernel_config_area.o als Voraussetzung hinzufügen muß (das ist sogar jetzt schon der Fall, iirc) und damit braucht es nur noch das passende Rezept, um diese .o-Datei (zum richtigen Zeitpunkt) zu erstellen, wobei dann natürlich erst mal die Assembler-Quelle (das .S-File) erzeugt werden muß im ersten Schritt. Auch dafür gibt es schon das passende Target in kernel.mk - und solange das nicht in den Build-Prozess einbezogen wird (weil die Konfiguration durch den Benutzer das so festlegt), braucht kein Schwein die Information, wie groß genau der Konfigurationsbereich im AVM-Kernel ist und was da drin steht.

Letztlich fällt der ganze Quatsch wohl (auch bei den GRX5-Boxen, die ja noch kein FIT-Image verwenden) bloß deshalb nicht weiter auf, weil die Option REPLACE_KERNEL nicht auswählbar ist für die meisten neueren Modelle.

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In den config/.img/ steht was das generate script (duch github actions ausgeführt) dazu ermittelt hat. 0 -> das tool ist nicht kompatibel
Das was in den .img (neu zur Beschleunigung: nur noch config/img.in) steht bewirkt was im menuconfig sichtbar ist: .image hat TAM -> remove-TAM auswählbar
Oder ob es replace kernel gibt.

Der kernel hat 3 stufen in freetz:

  1. auspacken für header - brauch man immer
  2. min 1 modul
  3. replace kernel.

2+3 sind im Grunde gleich, nur was ins Image kommt ist was anderes. AKC also auch...
selbst wenn man 1 kernelmodul mehr auswähl muss man nichts zusätzlich compilieren. Die Kernel config ist immer die von avm + Zusätze, aber alle als M-odul

Für nur-header kann man neuestens auch nur den vanilla source verwenden, wenn es klappt, siehe NEWS - 7530ax Inhaus hat eine ganz neue Kernelversion ohne Sourcen und auch ggc9, die läuft laut screenshot in einer discussion

Übrigens muss (by design) der kernel vorher wissen wie gross die AKC ist - ohne Wert baut es nicht. Du erinnerst dich? Das war anfangs ein Blocker als das tool die AKC nicht mehr ermitteln konnte - deshalb auch diese Ausnahme

replace-kernel geht für keinen v4 kernel. Ich hab davon absolut gar keine Ahnung, wenn jemand das machen will soll er. Ich hab auch keine Hardware zum testen

Dh für die Boxen für die replace kernel funktioniert passt es wie es ist - für alles weitere muss man schauen

@PeterPawn
Copy link
Owner Author

@PeterPawn PeterPawn commented on b8ec32d Jun 8, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Übrigens muss (by design) der kernel vorher wissen wie gross die AKC ist

Das wäre mir vollkommen neu (und ich dachte bisher, das "Prinzip" wäre noch dasselbe, wie ich es mal implementiert hatte) ... das muß er erst beim Linken wissen und die tatsächlich verwendete Größe steht dann auch (ggf. nur "indirekt" durch das danach erfolgende Alignment) im entsprechenden Linker-Control-File.

Siehe https://github.com/Freetz-NG/freetz-ng/blob/899d9bb66d4325670f5c3ff215be750d8d99969a/make/linux/patches/3.10.107/170-avm_kernel_config.PeterPawn.patch#L20, um mal als Beispiel den VR9-Kernel 3.10.107 "zu nennen" ... hier ist das "Gegenstück" für den 3.10.104 der GRX5-Boxen: https://github.com/Freetz-NG/freetz-ng/blob/899d9bb66d4325670f5c3ff215be750d8d99969a/make/linux/patches/3.10.104/170-avm_kernel_config.PeterPawn.patch#L20 und wie man (unzweifelhaft) sehen kann, ist da sogar diese Größe jeweils "fest kodiert" in den Patches, solange Du die nicht auch noch aus irgendwelchen anderen Daten "generieren" läßt. Am Ende hast Du also einmal diese Property, die "irgendwie" aus dem Kernel ermittelt werden soll (beim Generieren Deiner .img-Dateien) und parallel dazu steht da noch einmal ein "fester Wert" in den jeweiligen Patches für die Kernel-Version.

Wo genau ergibt das für Dich einen Sinn? Ich denke mal, das sollte ein "entweder oder" sein ... wenn man die Größe "ermitteln" will, dann sollte man das auch "durchhalten" und wenn man sie ohnehin irgendwo fest einstellen will/muß, dann kann man auf das Ermitteln auch verzichten. Beides gleichzeitig dürfte nur schwer zu begründen sein.

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

War es nicht so das er13 das so implementierte? Ich hab daran eigentlich nichts gemacht.
Ausser halt deaktiviert für Geräte bei denen dieser Wert nicht vorher bekannt ist, da er nicht ermittelt werden kann.
Das hatte doch das komplette compilieren (nur) der Module verhindert.

@PeterPawn
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Egal, wer das so in Freetz eingebaut hat ... warum sollte man es nicht einfach besser machen? Auch wenn im Moment nur noch wenige, ältere Modelle mit REPLACE_KERNEL unterstützt werden - soll das auch künftig so bleiben?

Ich habe Dir eigentlich alle "Fakten" aufgezählt, wann und wo man das am Ende (nur) braucht mit dem avm_kernel_config ... was Du daraus jetzt machst, ist Deine Sache. Ich dächte nur, daß es - wenn Du da nun schon am Build-Prozess herumschraubst - auch gleichzeitig eine gute Gelegenheit wäre, das auf die paar seltenen Fälle zu beschränken, wo es tatsächlich erforderlich ist. Wenn ich's nicht vollkommen falsch verstanden habe, wird es derzeit doch für all die Modelle ausgeführt, wo ..._AREA_SIZE_KNOWN am Ende NICHT gesetzt ist? Das wären ja einige, wie ich weiter vorne schon ausgeführt hatte.

Aber daß es sich bei diesem Vorgehen um "overkill" handelt, der gar nicht jedesmal und für jedes Modell ausgeführt werden muß, habe ich schon früher festgehalten, als Du Dich (bei mir) beschwert hast, daß das avm_kernel_config nur mit 32-Bit-Unterstützung funktioniert (den Thread dazu findest Du sicherlich selbst, es war iirc hier im GitHub) ... wenn's Dich mittlerweile nicht mehr stört, warum sollte es mir dann anders gehen? Vielleicht sollte ich mal wieder festhalten, daß ich selbst gar kein Freetz (und auch kein Freetz-NG) benutze?

@fda77
Copy link

@fda77 fda77 commented on b8ec32d Jun 9, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auch wenn im Moment nur noch wenige, ältere Modelle mit REPLACE_KERNEL unterstützt werden - soll das auch künftig so bleiben?

Das wird so bleiben bis es jemand ändert. Übrigens haben alle meine Modelle funktionierenden RK ;-)

wann und wo man das am Ende (nur) braucht mit dem avm_kernel_config

Ich versteh nicht was dein Problem ist. Es wird doch nur für wenige alte Geräte genutzt die kernel v3 haben und bei denen ausserdem dein+er13s tool die richtige AKC erkennt = _AREA_SIZE_KNOWN

wird es derzeit doch für all die Modelle ausgeführt, wo ..._AREA_SIZE_KNOWN am Ende NICHT gesetzt ist?

Geguggt? https://github.com/Freetz-NG/freetz-ng/blob/master/make/linux/kernel.mk#L200
Sind nur 24 Zeilen

Vielleicht sollte ich mal wieder festhalten, daß ich selbst gar kein Freetz (und auch kein Freetz-NG) benutze?

Ich kann jeden verstehen der kein fritzos nutzt, das ist aus meinem lan auch rausgeflogen

Please sign in to comment.