[Info] Fehlende Bestandteile im OpenSource-Paket von AVM

[PeterPawn]

@er13:
Ist mir nicht aufgefallen, so genau habe ich dann (zu meiner Schande) wieder nicht hingesehen.

Ich verstehe ja Dein Anliegen bei der Integration auch in gewissem Maße ... aber da die ganze Geschichte mit dem "avm_kernel_config"-Bereich ja nur dann überhaupt von Interesse ist, wenn der Freetz-Benutzer ohnehin ein "replace kernel" machen will, sehe ich das mehr als Tool für das Kompilieren eines kompletten Kernels an (was dann ohnehin stattfinden muß, wenn der Benutzer "replace kernel" verwenden will) als eines, was zu den Freetz-Tools gehört und die notwendige "Live-Kompilierung" der beiden Programme (und es wären eben beide, weil der "relocate"-Teil mit der Abhängigkeit von der AVM-Enum-Variablen in beiden verwendet wird) eher als "intermediate result", was man hinterher auch problemlos wieder entsorgen könnte (das spart das Aufbauen von komplizierten Abhängigkeiten für's "make" und der Zeitfaktor durch mehrfaches Kompilieren und Ausführen ist hier m.E. zu vernachlässigen).

Mit dem passenden Symlink im Verzeichnis kannst Du das ja auch problemlos "außerhalb der Kernel-Quellen" verwalten (allerdings eher nicht als "host tool", was nur einmal für die richtige Architektur übersetzt werden muß und daher dort einzuordnen wäre) und mußt nur am Ende die vom Assembler erzeugte Objekt-Datei zusammen mit dem Patch für das Linker-Skript (auch der ist bei der Größe nun mal modellabhängig und auch wenn wir im Moment nur zwei Größen kennen, würde ich das doch dynamisch an die AVM-Quellen anpassen, falls weitere "flavors" dazukommen) in den Baum mit den Kernel-Quellen kopieren. Wenn Du das dann wieder "restaurierst", hast Du auch einen "stabilen" Stand der Kernel-Quellen, den man (wenn man will) wieder für mehrere Modelle oder zumindest für mehrere Builds mit wechselnder Konfiguration beim "replace kernel" verwenden kann.

Aber auch das Einbinden mit absoluten Pfaden oder über Symlinks (dann brauchst Du gar nichts in den Kernel-Baum kopieren, änderst die Struktur aber auch wieder) wäre vielleicht eine Überlegung wert ... aber ich verstehe ohnehin noch nicht so ganz, wo Du die Grenzen der Änderungen ziehen willst bzw. was Dich bei dieser Differenzierung "Kernel vs. Freetz-Tools" nun wirklich antreibt.

Das sind nun mal leider drei verschiedene Level von "Volatilität" ... die (Prozessor-)Architektur ändert sich nur mit dem Prozessor-Modell (das braucht bisher nur den Rebuild der "host tools"), die Inhalte der FDTs ändern sich mit dem (FRITZ!Box-)Modell und die finalen Inhalte des Konfigurationsbereichs ändern sich sogar (wg. der Modul-Tabelle und der "version_info") für jede neue FRITZ!OS-Version.

Da sich auch der Aufbau des Konfigurationsbereiches mit jeder neuen FRITZ!OS-Version ändern kann (das weiß man erst, wenn man die Quellen hat und theoretisch könnte mit jedem neuen OS auch eine neue HWSubRevision in den FDT-Bereich Einzug halten), sehe ich auch die beiden Tools aus "avm_kernel_config" eher auf derselben Ebene bei ihrer "Vergänglichkeit", wie den Inhalt des Konfigurationsbereiches an sich ... und das bedeutet dann tatsächlich, daß man sie für jeden Build, bei dem sich der zugrundeliegende AVM-Kernel geändert hat, auch neu erstellen und benutzen muß (wenn man einen eigenen Kernel haben will) und sie bei den Abhängigkeiten für einen Build auch am ehesten dort unterbringt, wo ein neues AVM-Image entpackt wird. Man muß ja nicht jedesmal den kompletten Kernel übersetzen und entpackt wird der doch (m.W.) ohnehin, weil man ja die Include-Files für Userland-Programmierung auch braucht. Vielleicht brauchst Du ja auch eine neue "Kategorie" für solche Hilfsprogramme, die "image tools", die von der AVM-Version der Firmware abhängig sind und für jede dieser Versionen neu erstellt werden müssen.

 

[er13]

Ok, nochmal meine Motivation.

Background: in Freetz können unterhalb einer Working-Copy Images für mehrere Boxen erstellt werden, ohne dass dazwischen ein kompletter Clean notwendig wäre (man kann die .config anderer Boxen reinkopieren oder einfach mal über menuconfig umschalten). Ich weiß nicht, ob außer den Entwicklern dieses Feature jemand nutzt, aber ich finde es bei z.B. Version-Bumps sehr nützlich, da ich einfach testen kann, ob sich die neue Version des Pakets, bei dem der Version-Bump stattfindet, eben mit allen uClibc-Versionen (zumindest) übersetzen lässt.

Damit gilt per Definition, unter tools darf sich nur ein Tool befinden, welches "allgemeingültig" ist. Die Unterschiede dürfen sich nur auf folgendes beschränken: "wird für die Box gar nicht verwendet" oder "dem Tool werden Box-spezifische Parameter übergeben".

Und solange es nicht unbedingt notwendig ist, möchte ich auch bei avm_kernel_config_area-Tools nicht davon abweichen.

Warum möchte ich das. Es erscheint mir schlicht und ergreifend einfacher als das Ganze make-technisch umzusetzen. Denn (noch mal Background) in Freetz wird dasselbe OpenSource-Paket (oft gezwungenermaßen) für mehrere Boxen verwendet, das Umschalten der Box soll auch in dem Fall, dass für die Box, auf die umgeschaltet wurde, dasselbe OpenSource-Paket verwendet wird, dazu führen, dass Teile des Kernels neu übersetzt werden. Das wäre alles zwar möglich auch in dem Fall, wenn alles OpenSource-Paket spezifisch wäre, aber erfordert das Einschleusen von Freetz-Parametern in Kernel-Build-Environment, was ich bisher erfolgreich vermieden habe, und damit die Anzahl der Freetz-Kernel-Patches für AVM-OpenSource-Pakete klein gehalten habe.

Wenn man sich nun die Unterschiede zwischen 7490.06.80/avm_kernel_config.h und 7580.06.53/avm_kernel_config.h anschaut

--- 7490.06.80/avm_kernel_config.h
+++ 7580.06.53/avm_kernel_config.h
@@ -17,7 +17,253 @@
     avm_kernel_config_tags_device_tree_subrev_7,
     avm_kernel_config_tags_device_tree_subrev_8,
     avm_kernel_config_tags_device_tree_subrev_9,  /* subrev müssen aufeinander folgen */
-    avm_kernel_config_tags_device_tree_subrev_last = avm_kernel_config_tags_device_tree_subrev_9,
+    avm_kernel_config_tags_device_tree_subrev_10,
+    avm_kernel_config_tags_device_tree_subrev_11,
+    avm_kernel_config_tags_device_tree_subrev_12,
+    avm_kernel_config_tags_device_tree_subrev_13,
+    avm_kernel_config_tags_device_tree_subrev_14,
+    avm_kernel_config_tags_device_tree_subrev_15,
+    avm_kernel_config_tags_device_tree_subrev_16,
+    avm_kernel_config_tags_device_tree_subrev_17,
+    avm_kernel_config_tags_device_tree_subrev_18,
+    avm_kernel_config_tags_device_tree_subrev_19,
+    avm_kernel_config_tags_device_tree_subrev_20,
+    avm_kernel_config_tags_device_tree_subrev_21,
+    avm_kernel_config_tags_device_tree_subrev_22,
+    avm_kernel_config_tags_device_tree_subrev_23,
+    avm_kernel_config_tags_device_tree_subrev_24,
+    avm_kernel_config_tags_device_tree_subrev_25,
+    avm_kernel_config_tags_device_tree_subrev_26,
+    avm_kernel_config_tags_device_tree_subrev_27,
+    avm_kernel_config_tags_device_tree_subrev_28,
+    avm_kernel_config_tags_device_tree_subrev_29,
+    avm_kernel_config_tags_device_tree_subrev_30,
+    avm_kernel_config_tags_device_tree_subrev_31,
+    avm_kernel_config_tags_device_tree_subrev_32,
+    avm_kernel_config_tags_device_tree_subrev_33,
+    avm_kernel_config_tags_device_tree_subrev_34,
+    avm_kernel_config_tags_device_tree_subrev_35,
+    avm_kernel_config_tags_device_tree_subrev_36,
+    avm_kernel_config_tags_device_tree_subrev_37,
+    avm_kernel_config_tags_device_tree_subrev_38,
+    avm_kernel_config_tags_device_tree_subrev_39,
+    avm_kernel_config_tags_device_tree_subrev_40,
+    avm_kernel_config_tags_device_tree_subrev_41,
+    avm_kernel_config_tags_device_tree_subrev_42,
+    avm_kernel_config_tags_device_tree_subrev_43,
+    avm_kernel_config_tags_device_tree_subrev_44,
+    avm_kernel_config_tags_device_tree_subrev_45,
+    avm_kernel_config_tags_device_tree_subrev_46,
+    avm_kernel_config_tags_device_tree_subrev_47,
+    avm_kernel_config_tags_device_tree_subrev_48,
+    avm_kernel_config_tags_device_tree_subrev_49,
+    avm_kernel_config_tags_device_tree_subrev_50,
+    avm_kernel_config_tags_device_tree_subrev_51,
+    avm_kernel_config_tags_device_tree_subrev_52,
+    avm_kernel_config_tags_device_tree_subrev_53,
+    avm_kernel_config_tags_device_tree_subrev_54,
+    avm_kernel_config_tags_device_tree_subrev_55,
+    avm_kernel_config_tags_device_tree_subrev_56,
+    avm_kernel_config_tags_device_tree_subrev_57,
+    avm_kernel_config_tags_device_tree_subrev_58,
+    avm_kernel_config_tags_device_tree_subrev_59,
+    avm_kernel_config_tags_device_tree_subrev_60,
+    avm_kernel_config_tags_device_tree_subrev_61,
+    avm_kernel_config_tags_device_tree_subrev_62,
+    avm_kernel_config_tags_device_tree_subrev_63,
+    avm_kernel_config_tags_device_tree_subrev_64,
+    avm_kernel_config_tags_device_tree_subrev_65,
+    avm_kernel_config_tags_device_tree_subrev_66,
+    avm_kernel_config_tags_device_tree_subrev_67,
+    avm_kernel_config_tags_device_tree_subrev_68,
+    avm_kernel_config_tags_device_tree_subrev_69,
+    avm_kernel_config_tags_device_tree_subrev_70,
+    avm_kernel_config_tags_device_tree_subrev_71,
+    avm_kernel_config_tags_device_tree_subrev_72,
+    avm_kernel_config_tags_device_tree_subrev_73,
+    avm_kernel_config_tags_device_tree_subrev_74,
+    avm_kernel_config_tags_device_tree_subrev_75,
+    avm_kernel_config_tags_device_tree_subrev_76,
+    avm_kernel_config_tags_device_tree_subrev_77,
+    avm_kernel_config_tags_device_tree_subrev_78,
+    avm_kernel_config_tags_device_tree_subrev_79,
+    avm_kernel_config_tags_device_tree_subrev_80,
+    avm_kernel_config_tags_device_tree_subrev_81,
+    avm_kernel_config_tags_device_tree_subrev_82,
+    avm_kernel_config_tags_device_tree_subrev_83,
+    avm_kernel_config_tags_device_tree_subrev_84,
+    avm_kernel_config_tags_device_tree_subrev_85,
+    avm_kernel_config_tags_device_tree_subrev_86,
+    avm_kernel_config_tags_device_tree_subrev_87,
+    avm_kernel_config_tags_device_tree_subrev_88,
+    avm_kernel_config_tags_device_tree_subrev_89,
+    avm_kernel_config_tags_device_tree_subrev_90,
+    avm_kernel_config_tags_device_tree_subrev_91,
+    avm_kernel_config_tags_device_tree_subrev_92,
+    avm_kernel_config_tags_device_tree_subrev_93,
+    avm_kernel_config_tags_device_tree_subrev_94,
+    avm_kernel_config_tags_device_tree_subrev_95,
+    avm_kernel_config_tags_device_tree_subrev_96,
+    avm_kernel_config_tags_device_tree_subrev_97,
+    avm_kernel_config_tags_device_tree_subrev_98,
+    avm_kernel_config_tags_device_tree_subrev_99,
+    avm_kernel_config_tags_device_tree_subrev_100,
+    avm_kernel_config_tags_device_tree_subrev_101,
+    avm_kernel_config_tags_device_tree_subrev_102,
+    avm_kernel_config_tags_device_tree_subrev_103,
+    avm_kernel_config_tags_device_tree_subrev_104,
+    avm_kernel_config_tags_device_tree_subrev_105,
+    avm_kernel_config_tags_device_tree_subrev_106,
+    avm_kernel_config_tags_device_tree_subrev_107,
+    avm_kernel_config_tags_device_tree_subrev_108,
+    avm_kernel_config_tags_device_tree_subrev_109,
+    avm_kernel_config_tags_device_tree_subrev_110,
+    avm_kernel_config_tags_device_tree_subrev_111,
+    avm_kernel_config_tags_device_tree_subrev_112,
+    avm_kernel_config_tags_device_tree_subrev_113,
+    avm_kernel_config_tags_device_tree_subrev_114,
+    avm_kernel_config_tags_device_tree_subrev_115,
+    avm_kernel_config_tags_device_tree_subrev_116,
+    avm_kernel_config_tags_device_tree_subrev_117,
+    avm_kernel_config_tags_device_tree_subrev_118,
+    avm_kernel_config_tags_device_tree_subrev_119,
+    avm_kernel_config_tags_device_tree_subrev_120,
+    avm_kernel_config_tags_device_tree_subrev_121,
+    avm_kernel_config_tags_device_tree_subrev_122,
+    avm_kernel_config_tags_device_tree_subrev_123,
+    avm_kernel_config_tags_device_tree_subrev_124,
+    avm_kernel_config_tags_device_tree_subrev_125,
+    avm_kernel_config_tags_device_tree_subrev_126,
+    avm_kernel_config_tags_device_tree_subrev_127,
+    avm_kernel_config_tags_device_tree_subrev_128,
+    avm_kernel_config_tags_device_tree_subrev_129,
+    avm_kernel_config_tags_device_tree_subrev_130,
+    avm_kernel_config_tags_device_tree_subrev_131,
+    avm_kernel_config_tags_device_tree_subrev_132,
+    avm_kernel_config_tags_device_tree_subrev_133,
+    avm_kernel_config_tags_device_tree_subrev_134,
+    avm_kernel_config_tags_device_tree_subrev_135,
+    avm_kernel_config_tags_device_tree_subrev_136,
+    avm_kernel_config_tags_device_tree_subrev_137,
+    avm_kernel_config_tags_device_tree_subrev_138,
+    avm_kernel_config_tags_device_tree_subrev_139,
+    avm_kernel_config_tags_device_tree_subrev_140,
+    avm_kernel_config_tags_device_tree_subrev_141,
+    avm_kernel_config_tags_device_tree_subrev_142,
+    avm_kernel_config_tags_device_tree_subrev_143,
+    avm_kernel_config_tags_device_tree_subrev_144,
+    avm_kernel_config_tags_device_tree_subrev_145,
+    avm_kernel_config_tags_device_tree_subrev_146,
+    avm_kernel_config_tags_device_tree_subrev_147,
+    avm_kernel_config_tags_device_tree_subrev_148,
+    avm_kernel_config_tags_device_tree_subrev_149,
+    avm_kernel_config_tags_device_tree_subrev_150,
+    avm_kernel_config_tags_device_tree_subrev_151,
+    avm_kernel_config_tags_device_tree_subrev_152,
+    avm_kernel_config_tags_device_tree_subrev_153,
+    avm_kernel_config_tags_device_tree_subrev_154,
+    avm_kernel_config_tags_device_tree_subrev_155,
+    avm_kernel_config_tags_device_tree_subrev_156,
+    avm_kernel_config_tags_device_tree_subrev_157,
+    avm_kernel_config_tags_device_tree_subrev_158,
+    avm_kernel_config_tags_device_tree_subrev_159,
+    avm_kernel_config_tags_device_tree_subrev_160,
+    avm_kernel_config_tags_device_tree_subrev_161,
+    avm_kernel_config_tags_device_tree_subrev_162,
+    avm_kernel_config_tags_device_tree_subrev_163,
+    avm_kernel_config_tags_device_tree_subrev_164,
+    avm_kernel_config_tags_device_tree_subrev_165,
+    avm_kernel_config_tags_device_tree_subrev_166,
+    avm_kernel_config_tags_device_tree_subrev_167,
+    avm_kernel_config_tags_device_tree_subrev_168,
+    avm_kernel_config_tags_device_tree_subrev_169,
+    avm_kernel_config_tags_device_tree_subrev_170,
+    avm_kernel_config_tags_device_tree_subrev_171,
+    avm_kernel_config_tags_device_tree_subrev_172,
+    avm_kernel_config_tags_device_tree_subrev_173,
+    avm_kernel_config_tags_device_tree_subrev_174,
+    avm_kernel_config_tags_device_tree_subrev_175,
+    avm_kernel_config_tags_device_tree_subrev_176,
+    avm_kernel_config_tags_device_tree_subrev_177,
+    avm_kernel_config_tags_device_tree_subrev_178,
+    avm_kernel_config_tags_device_tree_subrev_179,
+    avm_kernel_config_tags_device_tree_subrev_180,
+    avm_kernel_config_tags_device_tree_subrev_181,
+    avm_kernel_config_tags_device_tree_subrev_182,
+    avm_kernel_config_tags_device_tree_subrev_183,
+    avm_kernel_config_tags_device_tree_subrev_184,
+    avm_kernel_config_tags_device_tree_subrev_185,
+    avm_kernel_config_tags_device_tree_subrev_186,
+    avm_kernel_config_tags_device_tree_subrev_187,
+    avm_kernel_config_tags_device_tree_subrev_188,
+    avm_kernel_config_tags_device_tree_subrev_189,
+    avm_kernel_config_tags_device_tree_subrev_190,
+    avm_kernel_config_tags_device_tree_subrev_191,
+    avm_kernel_config_tags_device_tree_subrev_192,
+    avm_kernel_config_tags_device_tree_subrev_193,
+    avm_kernel_config_tags_device_tree_subrev_194,
+    avm_kernel_config_tags_device_tree_subrev_195,
+    avm_kernel_config_tags_device_tree_subrev_196,
+    avm_kernel_config_tags_device_tree_subrev_197,
+    avm_kernel_config_tags_device_tree_subrev_198,
+    avm_kernel_config_tags_device_tree_subrev_199,
+    avm_kernel_config_tags_device_tree_subrev_200,
+    avm_kernel_config_tags_device_tree_subrev_201,
+    avm_kernel_config_tags_device_tree_subrev_202,
+    avm_kernel_config_tags_device_tree_subrev_203,
+    avm_kernel_config_tags_device_tree_subrev_204,
+    avm_kernel_config_tags_device_tree_subrev_205,
+    avm_kernel_config_tags_device_tree_subrev_206,
+    avm_kernel_config_tags_device_tree_subrev_207,
+    avm_kernel_config_tags_device_tree_subrev_208,
+    avm_kernel_config_tags_device_tree_subrev_209,
+    avm_kernel_config_tags_device_tree_subrev_210,
+    avm_kernel_config_tags_device_tree_subrev_211,
+    avm_kernel_config_tags_device_tree_subrev_212,
+    avm_kernel_config_tags_device_tree_subrev_213,
+    avm_kernel_config_tags_device_tree_subrev_214,
+    avm_kernel_config_tags_device_tree_subrev_215,
+    avm_kernel_config_tags_device_tree_subrev_216,
+    avm_kernel_config_tags_device_tree_subrev_217,
+    avm_kernel_config_tags_device_tree_subrev_218,
+    avm_kernel_config_tags_device_tree_subrev_219,
+    avm_kernel_config_tags_device_tree_subrev_220,
+    avm_kernel_config_tags_device_tree_subrev_221,
+    avm_kernel_config_tags_device_tree_subrev_222,
+    avm_kernel_config_tags_device_tree_subrev_223,
+    avm_kernel_config_tags_device_tree_subrev_224,
+    avm_kernel_config_tags_device_tree_subrev_225,
+    avm_kernel_config_tags_device_tree_subrev_226,
+    avm_kernel_config_tags_device_tree_subrev_227,
+    avm_kernel_config_tags_device_tree_subrev_228,
+    avm_kernel_config_tags_device_tree_subrev_229,
+    avm_kernel_config_tags_device_tree_subrev_230,
+    avm_kernel_config_tags_device_tree_subrev_231,
+    avm_kernel_config_tags_device_tree_subrev_232,
+    avm_kernel_config_tags_device_tree_subrev_233,
+    avm_kernel_config_tags_device_tree_subrev_234,
+    avm_kernel_config_tags_device_tree_subrev_235,
+    avm_kernel_config_tags_device_tree_subrev_236,
+    avm_kernel_config_tags_device_tree_subrev_237,
+    avm_kernel_config_tags_device_tree_subrev_238,
+    avm_kernel_config_tags_device_tree_subrev_239,
+    avm_kernel_config_tags_device_tree_subrev_240,
+    avm_kernel_config_tags_device_tree_subrev_241,
+    avm_kernel_config_tags_device_tree_subrev_242,
+    avm_kernel_config_tags_device_tree_subrev_243,
+    avm_kernel_config_tags_device_tree_subrev_244,
+    avm_kernel_config_tags_device_tree_subrev_245,
+    avm_kernel_config_tags_device_tree_subrev_246,
+    avm_kernel_config_tags_device_tree_subrev_247,
+    avm_kernel_config_tags_device_tree_subrev_248,
+    avm_kernel_config_tags_device_tree_subrev_249,
+    avm_kernel_config_tags_device_tree_subrev_250,
+    avm_kernel_config_tags_device_tree_subrev_251,
+    avm_kernel_config_tags_device_tree_subrev_252,
+    avm_kernel_config_tags_device_tree_subrev_253,
+    avm_kernel_config_tags_device_tree_subrev_254,
+    avm_kernel_config_tags_device_tree_subrev_255,
+    avm_kernel_config_tags_device_tree_subrev_last = avm_kernel_config_tags_device_tree_subrev_255,
     avm_kernel_config_tags_avmnet,
     avm_kernel_config_tags_last
 };

dann sieht man, dass AVM da nicht besonders kreativ war und dass mein Ziel im Wesentlichen dadurch erreicht werden kann, dass die Abhängigkeiten an avm_kernel_config_tags_device_tree_subrev_last und avm_kernel_config_tags_last eliminiert werden (avm_kernel_config_tags_avmnet wird in Deinem Code nicht verwendet).

Zu avm_kernel_config_tags_last habe ich einen Vorschlag in #53 gemacht (Du hast Dich dazu nicht geäußert, vermutlich den Edit übersehen). Wegen avm_kernel_config_tags_device_tree_subrev_last muss ich mir noch Gedanken machen.

Das Argument "in der nächsten Fritz!OS-Version könnte AVM es ändern" ist zwar absolut legitim, aber solange AVM das OpenSource-Paket dazu nicht veröffentlicht hat, bist Du eher in Schwierigkeiten, denn Du musst mit irgendwelchen Annahmen arbeiten. Da wäre dann die quasi automatische Erkennung von avm_kernel_config_tags_last (damit meine ich eher "der Code ist so, dass es ihm wurscht ist") ein Vorteil.

- - - Aktualisiert - - -

Edit: und ganz ehrlich, ich glaube nicht, dass AVM an avm_kernel_config.h bzw. an Enums/Strukturen darin was großartig ändern wird. Unter Umständen haben sie jetzt bei GRX5-Boxen für alle Zeit der Welt diese avm_kernel_config_tags_device_tree_subrev_* hinzugefügt und werden es nie wieder machen. Der Index vom letzten 255 ist da meiner Ansicht nach ein sehr starker Indikator dafür ;-)

 

[PeterPawn]

Bei der Schleife (die ist ja neu hinzugekommen, weil ich vorher immer nur Kernel mit einem einzigen FDT hatte bei der 7490) hast Du m.E. recht, aber an anderer Stelle als aufgezeigt bzw. wir haben da vermutlich wieder unterschiedliche Ideen.
[ EDIT: Quatsch, da habe ich mich ja auch nur verwirren lassen. Die Schleife geht eben von 0 bis "avm_kernel_config_tags_device_tree_subrev_last" und das ist ein anderer Wert (und auch der richtige) als "avm_kernel_config_tags_last", der dann tatsächlich größer wäre als der max. Index für eine HWSubrevision. ]

Die Schleife soll von 0 bis "subrev_last - subrev_0" gehen (also alle möglichen "subrevs" umfassen) - jedenfalls sollte dafür auch das fprintf() dann stimmen (bin zu müde für sinnvolle Überlegungen). Daß die Aufrufe für eine Subrevision jenseits von "subrev_last" hier nicht tatsächlich "out of bounds" gehen, liegt u.a. daran, daß aus "hasDeviceTree(i)" dann eben für alles jenseits von "last - subrev_0" ohnehin "false" zurückkommt. [ EDIT: Auch Unfug, siehe oben. ]

Wie man nun die Schleife gestaltet, ist aber auch egal ... entscheidend ist nur, daß am Beginn der Assembler-Datei die Liste der später folgenden FDTs stehen sollte, wobei die einmal einen Wert für den "reinen Index" (also "HWSubRevision") und einmal den Wert aus der Enum-Variablen (also HWSubRevision + subrev_0) für das Makro erwartet ... wobei Du gerne auch das Makro ändern und anstelle des "absoluten" Wertes 5 für "subrev_0" einen Namen ausgeben kannst. Aber normalerweise kennt das generierte Assembler-File die Enum-Variable bisher gar nicht und die Anlehnung der von mir generierten Label an die von AVM verwendeten Namen dient auch nur der besseren Übersicht und Vergleichbarkeit - damit heißt dann der FDT für subrev_0 eben auch so und nicht irgendetwas mit 5, was dem Enum-Wert entsprechen würde.

Deiner Vermutung bzgl. der "Konstanz" der AVM-Strukturen mag ich mich nicht so ganz anschließen ... wenn man sich die als Basis verwendeten Linux-Versionen ansieht, würde ich sogar sagen, daß die GRX500-Strukturen mit 256 möglichen Subrevisionen älter sind als die verbliebenen 10 in der Aufzählung bei der 7490 - ob die wieder bei allen VR9-Modellen gleich sind, weißt Du viel besser als ich, weil ich andere Quellen von AVM für VR9 gar nicht benutze.

Deiner Argumentation zum NULL-Pointer als (derzeitigem) Ende der Liste kann man ja problemlos in der ""init/avm_kernel_config.c" nachgehen:

  1 #include <linux/kernel.h>
  2 #include <linux/avm_kernel_config.h>
  3 #include <asm/prom.h>
  4
  5 struct _avm_kernel_config **avm_kernel_config;
  6 struct _avm_kernel_version_info *avm_kernel_version_info;
  7 struct _kernel_modulmemory_config *kernel_modulmemory_config;
  8 unsigned char *avm_kernel_config_device_tree[avm_subrev_max];
  9
 10 void init_avm_kernel_config(void) {
 11     const char *intro = "AVM Kernel Config";
 12     struct _avm_kernel_config *p;
 13
 14     if (init_avm_kernel_config_ptr()) {
 15         pr_err("[%s] %s failed\n", __func__, intro);
 16         return;
 17     }
 18     pr_err("[%s] %s (ptr %p)\n", __func__, intro, avm_kernel_config);
 19
 20     p = *avm_kernel_config;
 21
 22
 23     if (p == NULL)
 24         return;
 25
 26     while (p->tag <= avm_kernel_config_tags_last) {
 [COLOR="#FF0000"]27         if (p->config == NULL)
 28             return;[/COLOR]
 29
 30         switch (p->tag) {
 31             case avm_kernel_config_tags_undef:
 32                 pr_err("[%s] %s: undef entry\n", __func__, intro);
 33                 break;
 34             case avm_kernel_config_tags_modulememory:
 35                 pr_err("[%s] %s: module memory entry\n", __func__,
 36                         intro);
 37                 kernel_modulmemory_config =
 38                     (struct _kernel_modulmemory_config *)(p->config);
 39                 break;
 40         case avm_kernel_config_tags_version_info:
 41                 pr_err("[%s] %s: version info entry\n", __func__,
 42                         intro);
 43                 avm_kernel_version_info = (struct _avm_kernel_version_info *)(p->config);
 44         break;
 45             case avm_kernel_config_tags_last:
 46                 return;
 47             case avm_kernel_config_tags_avmnet:
 48                 pr_err("[%s] %s: unhandled avmnet entry\n", __func__,
 49                         intro);
 50                 break;
 51             case avm_kernel_config_tags_hw_config:
 52                 pr_err("[%s] %s: unhandled hw_config entry\n",
 53                         __func__, intro);
 54                 break;
 55             case avm_kernel_config_tags_cache_config:
 56                 pr_err("[%s] %s: unhandled cache_config entry\n",
 57                         __func__, intro);
 58                 break;
 59             case avm_kernel_config_tags_device_tree_subrev_0 ... avm_kernel_config_tags_device_tree_subrev_last: {
 60                      unsigned int index = p->tag - avm_kernel_config_tags_device_tree_subrev_0;
 61                      pr_err("[%s] %s: device-tree for subrev %d found\n", __func__, intro, index);
 62                      avm_kernel_config_device_tree[index] = (unsigned char *)((unsigned long)p->config + 0x00UL);
 63                  }
 64                  break;
 65         }
 66         p++;
 67     }
 68
 69     pr_err("[%s] %s: internal error, should not be reached.\n",
 70             __func__, intro);
 71 }
 72
 73 /* vim: set noexpandtab sw=8 ts=8 sts=0: */

[ AVM hat zwar keinen Header mit der Lizenz drin, aber packt das zum Kernel, damit darf man GPLv2 annehmen und ich habe das mal in vollem Umfang zitiert. ]

Nach Zeile 27 sieht AVM das mit der Abbruchbedingung genauso wie Du ... da stellt sich dann die Frage, was die Redundanz mit dem "..._last" überhaupt soll. Nun mag das reine Vorsicht des Programmierers gewesen sein, der das umgesetzt hat ... aber es gäbe ja keinen logischen Grund, da zwei unabhängige Kennzeichnungen des Listen-Endes zu führen und da sieht das für mich mehr nach einem (vorgezogenen) "avoid NULL pointer usage" (als "weak reference") für einige "cases" im nachfolgenden "switch"-Statement aus, falls doch mal (ich vermute, bei AVM sind das unabhängige Dateien bei der Übersetzung und auch beim Linken, die Offsets also "externe Adressen") etwas beim Linken fehlt.

Ich habe die denkbaren Abbruchbedingungen eigentlich nur 1:1 aus dem o.a. Code übernommen ... und da findest Du auch die Erklärung, warum ich auf die anderen - in der Enum-Variablen definierten - Typen von Einträgen verzichtet habe. Es gibt sie m.W. bisher schlicht nicht (zumindest wüßte ich nicht, bei welchem Modell das wäre) und sie werden auch vom AVM-Code als "unhandled" ausgewiesen, wenn sie dann trotzdem auftauchen. Damit ist die Chance, daß anderer Code darauf zurückgreifen will, meines Erachtens recht klein und ich habe nicht einmal bei allen anderen Typen eine Vorstellung, wie die Strukturen aussehen sollten, auf die "p->config" am Ende zeigt (und worauf der gecastet werden muß).

Also könntest Du wahrscheinlich tatsächlich den Rückschluß ziehen, daß der erste Eintrag, bei dem p->config NULL ist, auch derjenige ist, bei dem p->tag den (Integer-)Wert von "avm_kernel_config_tags_last" darstellt - aber dann kannst Du die Liste auch einfach beim ersten Auftreten eines NULL-Pointers in p->config mit zwei leeren Int32-Werten beschließen und mußt den Wert für "avm_kernel_config_tags_last" gar nicht mehr kennen. Der Test auf "avm_kernel_config_tags_undef" findet da ja gar nicht mehr statt, wenn das "p->config == NULL" schon vorher abbricht und wäre damit ebenfalls "unreachable", wenn Deine Annahme stimmen sollte und genauso wäre die Schleifenbedingung für das "while" in Zeile 26 obsolet.

Mich überrascht da zwar auch nichts mehr wirklich, aber ich hätte hier eher den Verdacht, daß der Test auf NULL für p->config eine spätere (schnelle, vielleicht nicht bis zum Ende durchdachte/abgesprochene) Änderung bei AVM darstellt und daß da eher ein "{ p++; continue; }" anstelle des "return;" stehen sollte. Wenn dann nämlich mal eines der (angenommenen) Symbole nicht aufgelöst werden kann, geht die Verarbeitung der Liste trotzdem weiter ... aber ich kann auch nur spekulieren, wie das bei AVM "spezifiziert" wurde und welche Implementierung nun richtig/beabsichtigt ist.

---

-Wobei ich immer noch nicht so ganz überzeugt bin, was die "Einordnung" als "host tool" durch Dich angeht - da kann ich Deine Erklärungen zwar verstehen, aber nicht nachvollziehen, warum Du das nicht einfach als "ganz normalen Schritt" beim Linken (auch wenn es davor auszuführen ist - dann ist es halt "Vorbereitung für's Linken") eines eigenen Kernels (und auch nur in diesem speziellen Fall muß das Extrahieren, Generieren und Assemblieren überhaupt stattfinden) ansehen willst. Sogar das Ermitteln der Größe braucht man nur unmittelbar vor der Verwendung ausführen und wer niemals einen eigenen Kernel verwenden will oder kann, der käme niemals in die Verlegenheit, diese Tools überhaupt benutzen zu müssen (und muß sie deshalb auch nicht erstellen).

Damit sind die für mich so weit von einem gemeinsamen Build mit den anderen "host tools" entfernt, daß ich das schon mental nicht zusammenkriege und wenn man den gesamten Ablauf zur Erstellung der Objekt-Datei einfach in ein passendes Skript-File verpackt, dann ist das auch nur ein zusätzlicher Aufruf dieses Skripts beim bzw. vor dem Linken eines eigenen Kernels.

Das muß gar nicht in irgendeine Kernel-Struktur eingebunden werden und damit ist es dann auch egal, ob die nun für ein einziges Modell oder für alle VR9-Modelle auf einmal verwendet wird. Der Kernel muß ja irgendwann ohnehin mal gelinkt werden und das ist ein Vorgang, der bisher nicht von FREETZ-Variablen beeinflußt ist und es auch in Zukunft nur so weit würde, daß da quasi ein "eigenes Kernel-Module" (avm_kernel_config_area.o) statisch dazugelinkt würde. Dafür reicht es ja schon, wenn man der Auflistung (in der Make-Variablen) "obj-y" dessen (kompletten) Dateinamen hinzufügt - dann kann das auch alles außerhalb der Kernel-Sources ablaufen und "verschmutzt" damit die Sourcen nicht so weit, daß die für den nächsten Build irgendwie erneut angefaßt werden müßten.

Das Patchen von Makefiles (und das geht dann ja auch komplett ohne irgendwelche Parametrierungen und damit ohne "modellspezifische" Patches, wenn man das alles in einer "geschlossenen Datei" laufen läßt und zwar inkl. der Ermittlung der korrekten Größe des Bereiches) ist ja nun gang und gäbe im Freetz, wenn ich mich in "make/linux/patches" so umsehe. Ich begreife ja in erster Linie nicht, warum da etwas "vorproduziert" werden muß und nicht einfach in dem Moment, wo man es braucht (und da ist dann das konkrete Modell auch genauso bekannt wie die aktuelle AVM-Firmware als Quelle der Daten) die Tools quasi "on the fly" erzeugt werden, die Datei generieren (ggf. inkl. Assembler-Lauf) und dann wieder komplett erledigt sind, bis man sie mal wieder braucht und dann werden sie eben erneut erstellt. Das kommt m.E. auch ihrem "Charakter" viel näher, als die irgendwo den "host tools" zuzuschlagen.

---

-Aber wie gesagt ... ich wollte eigentlich nur die Struktur "aufdecken" und erkunden, ob das berichtete Problem beim Bauen/Booten eines eigenen Kernels wirklich an diesen fehlenden AVM-Bestandteilen liegt oder nicht. Ob und wie Du das nun in die Freetz-Toolchain integrierst (das ist ja offenbar auch bei AVM im Build-Prozess automatisiert und die werden auch nicht für jedes Modell eine eigene Build-Umgebung pflegen, zumindest klingen einige Pfadnamen in den AVM-Komponenten nicht danach), entscheidest Du alleine ... ich gebe max. meinen Senf dazu, wenn ich Probleme mit mir bekanntem AVM-Code sehen sollte. Das ist beim "Listenende" nicht der Fall ... also mach' wie Du denkst.

 

[er13]

@Peter: ich habe mich a bißerl ausgetobt. Lass' mich wissen, ob es für Dich ok ist bzw. Du meine Pull-Requests akzeptieren würdest.

Ansonsten ist mir aufgefallen, dass der zweite Kernel bei den beiden GRX5-Boxen absolut identisch ist und das sogar unabhängig von der Fritz!OS-Version:

455a59eccfcdecfe61cc5e560c6bcfcf *FRITZ.Box_7560.149.06.53.kernel.image.unpacked.2ND
455a59eccfcdecfe61cc5e560c6bcfcf *FRITZ.Box_7560.149.06.81.kernel.image.unpacked.2ND
455a59eccfcdecfe61cc5e560c6bcfcf *FRITZ.Box_7580.153.06.54.kernel.image.unpacked.2ND
455a59eccfcdecfe61cc5e560c6bcfcf *FRITZ.Box_7580.153.06.81.kernel.image.unpacked.2ND

FDT_MAGIC ist in diesen 2 Mal zu finden. Vor dem ersten ist auch ein ordentliches config-area-array zu finden mit den Tags: 1(modulememory), 2(version_info), 5(device_tree_subrev_0), 6(device_tree_subrev_1) und 262(last). extract_avm_kernel_config scheitert jedoch sowohl für die Größe 96KB als auch für 64KB. Habe allerdings noch nicht debuggt, woran genau es liegt.

Edit: scheinbar stimmt beim 2.ten Kern die Annahme, dass die Config-Area an einer 4K Grenze liegt, nicht mehr. Der Offset lautet 0x0020ef70.

 

[PeterPawn]

@er13:
Das erscheint mir als extreme Verniedlichung dessen, was Du mit dem Code gemacht hast.

Ich will unsere Differenzen bzgl. der Design-Kriterien von wartbarem Code nicht erneut aufwärmen (auch nicht mehr in der Wunde der fehlenden "style guides" für Freetz herumbohren und die damit einhergehende Willkür, wann welche Art der Änderung nun besser wäre, erneut ausführlich diskutieren/thematisieren) ... ich hatte ja geschrieben: "Mach' was Du willst." Wenn es das ist, was Du willst (ich habe nach dem siebten Commit dann irgendwann aufgehört zu lesen), dann mach' es - aber erwarte bitte nicht, daß ich z.B. die Änderung der Schleifenbedingungen tatsächlich als "Verbesserung" sehe.

Wenn der von Dir neu formulierte Code funktioniert und in der Freetz-Toolchain das leistet, was Du von ihm erwartest: Schön. Damit ist das Thema für mich dann aber auch durch und da ich ohnehin für meine eigenen Zwecke einen anderen Weg der Integration verfolgen will und werde (ich habe - wie gesagt - die Commits gar nicht bis zum Ende angesehen, gehe aber fest davon aus, daß Du irgendetwas in der von Dir bereits angedeuteten Richtung umgesetzt haben wirst), werde ich zwar Deinen Vorschlag beim Vereinheitlichen der "has..."-Funktionen vermutlich aufgreifen (und ggf. auch weitere - noch nicht gelesene - sinnhafte Änderungsvorschläge; bisher gab es für mich da einfach noch keinen Grund zu einem solchen "Review" und das ist alles mehr oder weniger "organisch gewachsen" bei den Bemühungen, eine 1:1-Kopie der AVM-Daten zu erhalten), aber eher keine Pull-Requests übernehmen.

Das dabei notwendige "cherry picking" ist am Ende aufwändiger für mich, als eine eigene "Optimierung" - die ich sicherlich auch in Angriff genommen hätte, wenn mir jemand gesagt hätte, daß es für diese "Hilfsfunktion" (die nach meiner Erwartung immer noch eines Tages überflüssig werden sollte, wenn AVM dann wirklich komplette Quelltext-Pakete veröffentlicht) auch darauf ankommt, daß diese unbedingt ohne "code clones" auskommt und daß der Code unbedingt noch einer Optimierung unterzogen werden mußte, bevor er in Freetz Verwendung finden konnte.

Da wären dann (begründete) "Änderungsvorschläge" Deinerseits vielleicht doch der bessere Weg gewesen - wenn man sich überhaupt der Mühe unterziehen will, an so einer völlig banalen Stelle weitere Arbeitszeit zu investieren. Dieser Code wird weder ständig ausgeführt (muß also nicht besonders performant sein) noch ständig geändert (muß also auch nicht besonders "wartbar" sein) noch irgendwo auf einem Gerät mit begrenzten Ressourcen ausgeführt (muß also auch nicht besonders klein sein). Das macht in meinen Augen > 90% Deiner Änderungen komplett überflüssig und Du hättest Dich problemlos auf die weiter oben diskutierte Änderung beim Abbruch der Schleife beschränken können - eigentlich hättest Du dazu praktisch gar keinen Code anfassen müssen, da hätte eine "statische" Include-Datei mit einer der beiden Enum-Versionen von AVM vermutlich bereits gereicht, max. noch mit einer Änderung des fprintf() für das Ende der Liste.

Ich hatte mich mit dem "Mach' wie Du willst." vermutlich mißverständlich ausgedrückt (ich meinte "integriere wie Du willst") ... das war nicht unbedingt eine Aufforderung, den Code mal wieder um des reinen Änderns willen "auf links zu drehen" und anders kann ich das Ersetzen von "while"-Schleifen durch "for" und den Umbau der Schleifenbedingung beim Iterieren über die FDTs nicht bewerten. Ich kann es nicht verhindern ... aber ich muß darüber keineswegs "fröhlich" sein und schon gar nicht die komplette Liste an Commits in meine Version übernehmen. Wenn ich jemals in die Verlegenheit kommen sollte, den Code noch einmal anfassen zu müssen, dann ist es für mich eben entscheidend, daß der so aussieht, wie ich ihn geschrieben habe, wenn ich ihn ändern will oder soll - das macht es dann nämlich mir wieder einfacher, mir Funktion und Arbeitsweise ins Gedächtnis zu rufen.

Solltest Du noch einmal in die Verlegenheit kommen, eine derartige Aktion "in Erwägung ziehen zu müssen" (das erinnert mich so fatal an unsere Auseinandersetzung beim "mksquashfs" für die AVM-Version, daß ich erneut restlos bedient bin), dann wäre ich jedenfalls dankbar, wenn Du solche Änderungen zuvor wenigstens "ausdiskutieren" würdest und dann auch eine (nachvollziehbare) Begründung für solche Aktionen abliefern kannst. Die alte Aussage "Style-Guide gibt es nicht und brauchen wir auch nicht, ich mache das 'frei Schnauze' (und am Ende auch noch von Fall zu Fall und nicht etwa so, daß man sich auf irgendetwas einstellen kann)." ist jedenfalls keinesfalls eine passende Begründung in meinen Augen.

Auch hier würde ich wieder darum bitten, daß Du dann die Lizenz-Header der Dateien ergänzt, damit deutlich erkennbar wird, daß es sich hier nicht ausschließlich um etwas handelt, was ich geschrieben habe. Nicht jeder ist automatisch der Meinung, daß Dein Stil beim Schreiben von C-Programmen der bessere ist (vielleicht solltest Du "while" als Code-Konstrukt aus dem Standard streichen lassen?) und wenn Du den Code schon "verbesserst" (danke, daß es kein Rotstift war), dann stehe bitte auch zu Deinen Änderungen.

 

[er13]

Wow, so eine Antwort habe ich nicht erwartet, insbesondere den Ton zwischen den Zeilen. Nichtsdestotrotz schlucke ich das jetzt und versuche sachlich dagegen zu argumentieren bzw. meine Motivation darzulegen.

Ich finde es sehr schade, dass Du die Commits (wie Du es sogar selber betont hast) nicht bis zum Ende angeschaut hast und auf Basis Deiner Annahmen, Schlussfolgerungen gezogen hast... Da wäre es besser mit der Antwort einige Zeit zu warten, die Commits bis zum Ende anzuschauen und ggf. explizit nachzufragen, um Deine Annahmen zu bestätigen oder vielleicht auch zu widerlegen.

Zu meiner Motivation: alle meine Commits kann man in folgende Kategorien unterteilen:

1. Whitespaces cleanups: 87aaad1, 9defda1 (wobei bei diesem Commit, die Änderungen streng genommen zu dem funktionalen Commit unmittelbar davor gehören und mit Absicht aus diesem ausgelassen wurden).

2. Verbesserung der Verständlichkeit des Codes, diese halfen mir Deinen Code zu verstehen (der nun mal nicht an allen Stellen für sich sprechend ist) und teilweise, wenn ich mich nicht vertan habe, Fehler in diesem aufzudecken: 2b549ad, 1e43c07, eb8443c (mit Fehler aufdecken ist dieser Commit gemeint), aa4dc6d.
Dein Argument, der Code "wird nicht so oft geändert, deswegen muss er auch nicht besonders wartbar sein" kann ich nicht nachvollziehen. Jetzt haben zwei Leute daran gearbeitet bzw. arbeiten müssen/wollen und der zweite kam nicht sofort damit zurecht (im Sinne brauchte Zeit, um den Code zu verstehen zwecks seine Anpassungen durchführen zu wollen). Allein das ist schon Grund genug, um etwas Zeit in die bessere Verständlichkeit und damit die Wartbarkeit zu investieren.

3. Vereinfachung/Verschönerung des Codes (dienen am Ende auch ausschließlich der besseren Wartbarkeit): fa4d0e7, 7f77f2d,
5e3304c. Der letzte Commit ist in der Tat subjektiv, ich finde die for-Schleifen an diesen Stellen leichter zu lesen. Man beachte, ich habe es nicht überall geändert, deswegen fand ich den Ton des folgenden Satzes von Dir völlig unangebracht: "vielleicht solltest Du "while" als Code-Konstrukt aus dem Standard streichen lassen".

4. Fehler/typos korrigieren (die Fehler hinderten mich an meinem Endziel): 5e30001, 7e8c2cf

5. Die wichtigsten Vorbereitungscommits: fd958f4, 24e847b, 89dee38, 734e467
Das Ziel von diesen war, die Anzahl der Verwendungen von avm_kernel_config_tags_last zu minimieren. Dafür musste unter anderem die Anzahl der Schleifen, in denen über das Config-Area-Array iteriert wird, verkleinert wird. Man beachte, es geht um die Anzahl Vorkommnisse und nicht um die Performance-Optimierung, wie Du fälschlicherweise annimmst. Das Ändern des Abbruchkriteriums bei der Iteration half auch die Anzahl Vorkommnisse von avm_kernel_config_tags_last zu minimieren.

6. Der Hauptcommit: df5c65d
Die Anzahl der #ifdef's in diesem ist durch die Vorbereitungsmaßnahmen sehr gering und die Idee von diesem ist in der Commit-Messge beschrieben. Es kann durchaus sein, dass die Annahmen von diesem irgendwann mal nicht gelten, aber momentan ist es so.

Warum Du plötzlich Style-Guides ansprichst, kann ich nicht nachvollziehen (Änderungen dieser Art hatte ich bei keinem Commit als Ziel). Es sei jedoch darauf hingewiesen, dass auch Du keine hast, die irgendwo aufgeschrieben wären. Mir sind beim Anpassen Deines Codes folgende Verstösse meinerseits gegen Deine (von mir aus Deinem Code abgeleitete) Style-Guides aufgefallen/bewusst. Die "{"-Klammer beginnt an einigen Stellen in derselben Zeile anstatt in der neuen (kann ich korrigieren). Manche "if (condition) return"-Zeilen habe ich vor dem "return" umbrochen. Bei mir ist der Umbruch vor dem return unabdingbar (denn genau in dieser Zeile wird dann der Breakpoint in dem Debugger gesetzt), aber auch das kann ich ändern.

Die Freetz-C-Code-Style-Guides nehme aus dem gegebenen Anlass in Angriff. Mir ist erst vor kurzem ein Open-Source-Projekt aufgefallen, in dem es sehr gut beschrieben war, inkl. einer Konfiguration für ein Auto-(Re-)Format-Tool.

Lizenz-Header passe ich auch an, i.e. trage da meinen Namen ein.

 

[PeterPawn]

@er13:
Nun steh' aber auch bitte dazu, was da (wieder einmal) passiert ist und auch wenn ich von

Aber wie gesagt ... ich wollte eigentlich nur die Struktur "aufdecken" und erkunden, ob das berichtete Problem beim Bauen/Booten eines eigenen Kernels wirklich an diesen fehlenden AVM-Bestandteilen liegt oder nicht. Ob und wie Du das nun in die Freetz-Toolchain integrierst (das ist ja offenbar auch bei AVM im Build-Prozess automatisiert und die werden auch nicht für jedes Modell eine eigene Build-Umgebung pflegen, zumindest klingen einige Pfadnamen in den AVM-Komponenten nicht danach), entscheidest Du alleine ... ich gebe max. meinen Senf dazu, wenn ich Probleme mit mir bekanntem AVM-Code sehen sollte. Das ist beim "Listenende" nicht der Fall ... also mach' wie Du denkst.

geschrieben habe, war das wohl kaum als Bitte um das komplette Umschreiben und die Korrektur meiner "Fehler" mißzuverstehen.

Du hast erneut(!) aus einer fremden Software ohne unmittelbare Notwendigkeit "Deine eigene" gemacht und anstatt solche Änderungen erst einmal vorzuschlagen und zu diskutieren, wolltest Du es erneut sofort "besser" machen. Das ist eben nicht nur ein "Vorschlag" Deinerseits, der sich in verschiedene Commits aufteilt und den man nun gar selektiv irgendwie per Pull-Request übernehmen könnte. An Selbstvertrauen und Ellenbogen mangelt es Dir an dieser Stelle ganz offensichtlich nicht ... ich persönlich finde es aber schon recht kühn, wenn man seine eigenen Commits als "improvement" oder "make something better" eincheckt und diese Einschätzung nur auf der eigenen Sichtweise basiert.

Wie das vielleicht weniger "aufdringlich" geht, kannst Du Dir gerne bei diesem Patch meinerseits einmal ansehen: https://github.com/PeterPawn/freetz...90ed39a#diff-6a981f53e4f6bc52233bae4c3645db31 - ich halte auch diesen für "better" (und begründe das sogar noch im Commit-Text, warum ich das so sehe), aber eben nicht mit "improve" und "better", sondern als "different approach". Nenn' es Zurückhaltung (eigentlich so gar nicht eine meiner hervorstechendsten Eigenschaften) oder wie Du willst ... Fakt ist jedenfalls, daß Du in der Vergangenheit, als Du von mir auf diesen Patch angesprochen wurdest, nicht minder "erregt" reagiert hast und Deine Argumentation als "Es funktioniert doch auch in meiner Version, was willst Du eigentlich von mir?" zusammengefaßt werden kann.

Wie auch immer, das ist alles meinerseits unter GPLv2 gestellt und Du darfst es ändern, wie Du willst. Bei meiner Reaktion spielte es aber durchaus auch eine Rolle, daß Du (wieder einmal, also kann ich das auch nicht als "Unfall" ansehen) Deinerseits sofort vollendete Tatsachen geschaffen hast (daran ändert es auch absolut nichts, ob man nun Deine Änderungs"vorschläge" als sinnvoll ansieht oder sie - zumindest in Teilen - ablehnt), denn die Uhrzeit von http://freetz.org/changeset/14205 liegt deutlich vor Deinem Beitrag von 01:33 Uhr. Damit wurden aber bereits "Fakten geschaffen" und Du hast erneut Deine eigene Version (ohne jede weitere Diskussion oder auch nur die Möglichkeit dazu) als "die bessere Alternative" eingeschätzt und in Freetz übernommen.

Ich brauche - ehrlich gesagt - auch die nachgereichte Begründung für die einzelnen Commits nicht (lesen kann ich ja durchaus, wenn ich das auch will) ... trotzdem gerne meinerseits die eigenen Kommentare zu Deinen Commits:

- Dein Punkt 4 oben ist - sogar in der "Begründung" - in meinen Augen eine Zumutung, wenn es um 5e30001 geht. Für die zwei Tippfehler im anderen Commit ist das "geschenkt" ... aber wieso Deine Änderung in 5e30001 ein "fix" ist, erschließt sich mir in der Begründung nicht. Das mag ein "change" sein, wenn man Deinen "Endsieg" Dein Endziel zugrunde legt, aber das ist eben keine "Reparatur" irgendeiner nicht funktionierenden Konstruktion. Nun kannst Du Dich nach der Korrektur meines Fehlers bei der Verwendung des Singulars von "go" im "past tense" auch nicht darauf herausreden, daß Dir derartige Unterschiede "nicht geläufig" wären.

- Deine Commits bauen durchaus aufeinander auf, ohne daß es aus dem Begleittext ersichtlich wäre (z.B. ist fa4d0e7 ohne 2b549ab falsch) und damit bleibt/bliebe mir bei der Übernahme von Pull-Requests gar nichts anderes übrig, als das jeweils meinerseits noch einmal komplett zu "reviewen".

- Nach Deinen Änderungen hat sich eben auch die Logik des Codes geändert. Während es für mich die oberste Priorität hatte, daß der Code (im Rahmen seiner Möglichkeiten, auf die fehlenden Informationen zu den anderen "tags"-Werten und den dabei verwendeten Strukturen habe ich schon hingewiesen) eine 1:1-Kopie des AVM-Formats erzeugen wird und kann (schon um Nachfragen oder Kritik an dieser Stelle zuvorzukommen), änderst Du das ebenfalls "mit einem Federstrich". Es steht meines Wissens nirgendwo geschrieben, daß die FDTs in diesem Bereich nur in streng aufsteigender Folge der "HWSubRevision" hinterlegt werden müssen - dank des Codes in "init/avm_kernel_config.c" (den Du auch kanntest bzw. kennen konntest, ich habe ihn oben komplett eingefügt) wird die jeweilige Adresse in ein Array unter dem richtigen Index eingetragen und auch eine Reihenfolge 0, 3, 1 läge im Rahmen der Möglichkeiten bzw. würde mit dem veröffentlichten AVM-Code funktionieren. Das ist bei Deinem Iterieren über die FDTs aber nicht mehr der Fall ... und selbst wenn es das bei AVM gar nicht geben sollte (ich weiß es nicht, aber Du kannst es eigentlich auch nicht wissen) oder es bei den Teilen, die AVM veröffentlicht, vermutlich auch gar keine Rolle spielt (auch hier weiß keiner von uns, was in den LKM von AVM ggf. noch passiert), ist das eine Änderung meines Paradigmas, daß eine 1:1-Kopie erzeugt werden soll.

- Die Frage, ob eine Formulierung:

if (!(avm_kernel_config_tags_undef < tag && tag <= avm_kernel_config_tags_last))
		return false;

besser und leichter zu lesen ist, als es

if (tag != 0 && tag > avm_kernel_config_tags_last) return false;

wäre (die 0 hätte ich tatsächlich gegen die Enum-Variable für "undef" tauschen können, das wäre die einzige von mir "akzeptierte" Änderung), liegt sicherlich auch im Auge des Betrachters ... Negation und Klammerung machen es eben gerade nicht einfacher, den Sinn nachzuvollziehen, solange man sich nicht ständig damit befaßt. Auch an anderen Stellen bist Du offenbar "Fan" von Ausdrücken, an denen sich "Nicht-Programmierer" (und nicht jeder hat Boolesche Algebra resp. die "De Morganschen Regeln" mit der Muttermilch eingesogen oder hat das Bedürfnis, "Klammern auszuzählen") das Hirn verrenken können:

	if (!((avm_kernel_config_tags_device_tree_subrev_0 <= entry->tag) && (entry->tag <= avm_kernel_config_tags_device_tree_subrev_last)))
return;

... aber das ist tatsächlich eine Frage des eigenen Stils und der eigenen Erwartungshaltung, an wen sich diese Zeilen am Ende richten und wer sich einem "Review" widmen wird. Nur Deine Haltung, daß Deine Art der Formulierung die einzig richtige ist und daher diese auch "durchzudrücken" wäre, geht mir auf den Zeiger.

- Das gilt genauso für Deinen Commit 9defda1 ... wenn ich hingehe und in meinem Code die lokalen Definitionen so formatiere, daß nach der längsten Typ-Definition die Namen an einer einheitlich eingerückten Stelle stehen (und die Anzahl der Tabulatoren war ja nicht ausgewürfelt, die hatten ihren Sinn), dann empfinde ich diesen Commit als "äußerst aufdringlich", weil auch hier wieder der Impetus anklingt: "Ich weiß es viel besser als Du, wie man so etwas richtig formatiert.". Die Datei enthielt eine "modeline" für die unter Linux üblichen Editoren in Zeile 1 und damit wäre es eben an Dir gewesen, Deinen Editor auf 4 Zeichen Tabulator-Breite einzustellen (wenn er das nicht automatisch auf die Reihe kriegt dank der "modeline") und nicht, mir mal zu zeigen, wie man "richtig formatiert" (daher mein Verweis auf "style guides"). Immerhin beruhigt mich aber Dein Tippfehler mit dem doppelten "i" im Commit-Text dann dahingehend, daß auch Du nicht vor "typos" gefeit bist.

- Wenn Du tatsächlich erkannt haben solltest, daß Deine Änderungen der "while"- in "for"-Schleifen "rein subjektiv" waren, erklärt das aber immer noch nicht, warum nun Dein (subjektives) "Schönheitsempfinden" (das gilt auch für die Formulierung "Vereinfachung/Verschönerung des Codes") das sein sollte, was hier "gewinnt". Auch hier komme ich wieder auf "style guides" zurück und Dir ist sicherlich nicht entfallen, daß wir bereits in der Vergangenheit an dieser Stelle ernsthafte und erbitterte Debatten hatten. Ich empfinde es in der Tat als äußerst "ungehörig", wenn jemand stets und ständig in den Quelltexten anderer "herumändert", nur um seine eigenen Vorstellungen (und die sind eben weder "festzumachen" noch irgendwo niedergeschrieben oder gar "abgestimmt") obsiegen zu lassen. Das ist für mich keine "Zusammenarbeit", wie sie nun einmal in Community-Projekten notwendig ist (da muß man auch die Arbeitsweise von anderen akzeptieren oder man einigt sich eben auf solche "style guides") und unsere Meinungsverschiedenheiten an dieser Stelle waren ja auch der Auslöser dafür, daß ich meinen Trac-Account gelöscht habe und dort gar nichts mehr schreibe. Ich hatte die Hoffnung, daß es Dir gelingen würde, Dich in dieser Richtung auch etwas zurückzunehmen ... nach dem, was Du hier gezeigt hast, war das offensichtlich ein Irrtum meinerseits.

Aber das ist mir am Ende auch egal ... ich wollte nur eine Erklärung/Begründung geben, warum ich nicht voller Euphorie auf Deinen Fork und Deinen Text in #57 reagierte. Noch einmal: Das steht alles unter GPLv2, Du kannst das forken und ändern, wie Du möchtest ... ich bin allerdings nicht bereit, bei künftigen Änderungen durch AVM und an mich "delegierten" Recherchen/Änderungen an dieser Stelle, auf der Basis Deiner Änderungen fortzufahren - mich "überzeugen" eben lange nicht alle Deine Commits und das Lesen wird (für mich jedenfalls) dadurch auch nicht zwangsläufig einfacher. Solange es nicht einen Dritten in der Rolle des "Schiedsrichters" gibt (oder eben abgestimmte(!) "style guides" und insofern bin ich bei "Die Freetz-C-Code-Style-Guides nehme aus dem gegebenen Anlass in Angriff." auch ein wenig skeptisch, inwieweit diese dann die Auffassung mehrerer oder doch nur eines einzelnen wiedergeben werden), ist das aber auch alles Spiegelfechterei, was wir hier betreiben und ehe es wieder zu "richtig schlechter Stimmung" kommt, würde ich das Thema dann auch begraben wollen.

 

[PeterPawn]

Ärger dich nicht darüber [...]

Das mache ich auch nur in sehr begrenztem Umfang - und ich wollte in #58 auch mehr meinem Erstaunen Ausdruck verleihen, als etwas "zwischen den Zeilen anklingen zu lassen". Das war (meines Erachtens jedenfalls) noch eine ganz sachliche Feststellung, daß da bei den Änderungen für mich etwas über das eigentliche Ziel hinausgeschossen wurde ... oder ich habe meinerseits schlicht dieses "eigentliche Ziel" falsch verstanden.

Gerade angesichts der bekannten Differenzen an dieser Stelle hätte ich eben mehr Zurückhaltung und die Beschränkung der Änderungen auf das Notwendige erwartet ... daraus resultierte dann wirklich "Erstaunen" und es kam überhaupt erst Unmut bei mir auf, nachdem in der 5. Änderung dann meine Formatierung des Codes "nicht konvenierte" (schon die erste dahingehende Änderung war recht überflüssig, weil "trailing whitespace" vollkommen uninteressant ist an dieser Stelle und höchstens ein "patch" mit ungeeigneten Optionen sich davon irritieren läßt) und in der 7. Änderung dann eine Umbenennung einer Funktion erfolgte.

Bis zu diesem Zeitpunkt hatte ich schon jede Menge Zeit in das Lesen investiert, aber außer dem dritten Commit (wo dann die "hasSomething"-Funktionen zusammengefaßt wurden, was - je nach Auffassung - auch nicht "ganz sauber" ist) war mir nur der vierte "untergekommen", bei dem mir eben sofort auffiel, daß damit auch die Logik des Ablaufs geändert wird und anders aufgebaute Eingabedaten zu einem (von @er13 vermutlich nicht berücksichtigten) abweichenden Ergebnis führen würden. Da hatte ich dann irgendwann auch "die Nase voll" und habe mir einfach aus diesem Grund den Rest gar nicht weiter angesehen (im ersten Anlauf) - es war für mich zu diesem Zeitpunkt einfach klar, daß ich das mit höchster Wahrscheinlichkeit nicht 1:1 "nachziehen" würde. Mein Kommentar, daß ich nicht alles gelesen habe, war eigentlich auch gar nicht "böse gemeint" ... das war nur ehrlich und sollte gleichzeitig als "Entschuldigung" dienen, wenn ich nachfolgende, wirklich wichtige Änderungen damit auch nicht ausreichend würdigen könnte.

Ich muß eben auch noch im Hinterkopf behalten, daß ich "beim Probieren" schon mal irgendwo eine zusätzliche Protokoll-Ausgabe einbauen muß (und die gab es tatsächlich schon einmal) und da ist schon die "hasTag()"-Funktion ein durchaus zweischneidiges Schwert, wenn es gleichzeitig noch um "design principles" geht (die dann wieder "verbieten", daß so eine allgemeine "hasTag()"-Funktion intern wieder weiter nach unterschiedlichen Tags differenziert).

Wäre das hier C++ und es gäbe die Möglichkeiten der OOP (Basisklassen, Polymorphismus, Vererbung), wäre es keine Hürde, die einzelnen "Typen" von "configEntries" mit einer solchen Basisklasse zu implementieren und die ggf. noch zusätzlich notwendigen Validierungen oder Trace-Protokollierungen in Form von überladenen Methoden zu realisieren, wenn die Methode der Basisklasse dafür nicht ausreicht. Hier hätte man aber eher bei den von mir genutzten "hasSomething()"-Funktionen bleiben und dann ggf. den wirklich gemeinsamen Code in eine zusätzliche Funktion auslagern sollen - dann kann man nämlich die Validierungen für die unterschiedlichen "configEntries" immer noch unabhängig von anderen (und ohne Änderung von "hasTag()") erweitern.

Der zusätzliche "Funktionsaufruf" für diesen gemeinsamen Teil kann jedenfalls nicht das entscheidende Kriterium für das "komplette Einstampfen" der typspezifischen "has...()"-Funktionen gewesen sein, denn der Aufruf in

processDeviceTreeEntry(findEntry(configArea, tag));

, wo dann "processDeviceTreeEntry()" für einen NULL-Wert als Ergebnis von "findEntry()" sofort wieder zurückspringt, funktioniert nach demselben Prinzip und diese Anweisung wird bei einer 7580 sogar 256x ausgeführt.

Es gibt eben (fast) immer mehrere "richtige" Lösungen und man muß deren Vor- und Nachteile auch immer von Fall zu Fall gegeneinander abwägen ... daher regt es mich ja auch so auf, wenn jemand nur seine eigenen Ansichten an dieser Stelle akzeptieren will und an die Stelle einer (gemeinsamen) Abwägung einfach seine eigenen Änderungen setzt.

Aber noch einmal und explizit auch als "Beruhigung" an @er13: Das ist alles durchaus legitim und soll meinetwegen auch so geschehen ... ich erwarte nur meinerseits auch Verständnis, wenn ich das nicht alles kritiklos übernehme, was da jemand anderes seinerseits als "besser" einschätzt und das obendrein noch in einer Situation, wo mich derjenige gar nicht erst gefragt hat, was ich mir dabei gedacht habe (oder ob ich überhaupt gedacht habe). Wenn ich gute Gründe für die eine oder andere Entscheidung gehabt haben sollte, interessierten die hier offenbar niemanden. Da muß es aber auch nicht verwundern, wenn ich mit einer - auf diese Weise - geänderten Version dann nichts mehr zu tun haben will. Ein "Ich weiß doch ohnehin besser, wie man das richtig macht." ist jedenfalls nicht dazu angetan, daß man sich überhaupt noch bemüßigt fühlt, irgendetwas zu schreiben und anderen zur Verfügung zu stellen - das schließt eine berechtigte und begründete(!) Kritik/Diskussion noch lange nicht aus, nicht daß man das jetzt mißversteht. Aber wenn jemand mit mir über die "whitespaces" in einem Quelltext diskutieren will, ist einfach auch das Ende der Fahnenstange erreicht.

 

[er13]

Ich habe mir detailliert Deine Antworten durchgelesen und habe sogar zu recht vielem eine Antwort geschrieben bis ich bei irgendeiner Deiner Antworten eingesehen habe, dass Du schon längst persönlich bist, dass der Grad Deiner Voreingenommenheit mir gegenüber so hoch ist, dass Du fast geblendet davon bist und damit (zumindest zum aktuellen Zeitpunkt) jegliche Fortführung der Diskussion egal auf welchem sachlichen, argumentativen Niveau keinen Sinn macht.

Ich lasse daher das von Dir gesagte bewusst unbeantwortet, denn meine Antworten würden vermutlich nur zu einer Eskalation des Ganzen führen. Das möchte ich nicht und habe zugegebenermaßen auch keine Zeit und keine Lust dazu.

Ich werde dann wohl einen Fork pflegen müssen. Schade, aber dann ist es nun mal so.

 

[PeterPawn]

@Gene:
Ich denke mal, das siehst Du falsch ... ich habe gerade in letzter Zeit m.E. auch per E-Mail mit Dir in einer Form kommuniziert (und kommunizieren können), die mich nicht erwarten ließ, daß Du erneut mit einem solchen "Ausrutscher" um die Ecke kommen würdest.

Wenn das aber der Fall ist (und hier ist das in meinen Augen nun einmal so), dann nehme ich auch mein Recht wahr, das ganz deutlich zu kritisieren. Solltest Du tatsächlich in einem der von mir aufgeführten Kritikpunkte einen persönlichen Angriff sehen und der Überzeugung sein, daß ein solcher (also ein Punkt der Kritik ist hier gemeint, nicht ein Angriff) bar jeder Berechtigung wäre, dann bin ich nur zu gerne bereit, mich mit Dir darüber auszutauschen. Das Einzige, was ich nicht noch einmal will, ist eine solche "Diskussion" im stillen Kämmerchen (per E-Mail oder PN) - wenn Du Dein Vorgehen für genauso berechtigt hältst, wie ich es für das meine reklamiere, dann sollte es auch kein Problem sein, so eine Kontroverse öffentlich und trotzdem sachlich auszutragen.

Wenn Du die von mir geäußerten Kritikpunkte an Deinem Vorgehen wirklich so gar nicht nachvollziehen kannst, dann versetze Dich einfach einmal in meine Lage (oder in die jedes anderen, der seinen Beitrag leisten will) und überlege Dir, wie Du auf derart massive Eingriffe reagieren würdest (und reagiert hast, ich suche gerne auch den entsprechenden Beitrag heraus, falls Du Dich nicht mehr erinnern kannst).

Wie Du auf die (falsche) Idee kommst, ich wäre "fast geblendet von meiner Voreingenommenheit Dir gegenüber", kann ich nicht nachvollziehen ... es ging ja eine ganze Weile recht gut. Ansonsten gilt eben "An ihren Taten sollt ihr sie erkennen." (ist m.W. irgendwo aus einem "Testament", da kenne ich mich nicht aus) und diese Taten waren im hiesigen Fall nun einmal dazu angetan, eine Kritik in dieser Richtung auszulösen bzw. zu befördern. Wenn irgendeiner der von mir angeführten Punkte unwahr sein sollte (da spielt es auch keine Rolle, wie Du das ggf. "gemeint" hast - es zählt das, was Du getan und geschrieben hast), dann korrigiere ich das gerne - überzeuge mich, daß ich das "übertreibe", was ich da kritisiere.

Ich bin also nicht in blinder Voreingenommenheit Dir gegenüber gefangen, ich lasse mir nur nicht alles gefallen, was Du vielleicht als "normal" ansehen magst. Gerade dann, wenn Du Dein Verhalten als "vollkommen in Ordnung" bezeichnen und es immer wieder so machen würdest, solltest Du m.E. das vorher ganz klar kundtun und vielleicht auch begründen, warum Du das als zielführend ansiehst (wenn dann ggf. niemand mehr mit Dir arbeiten will).

Da wirkt dann ein "Ich lasse das bewußt unbeantwortet stehen." auch nicht überzeugend - wenn man das sachlich diskutiert (und ich sehe auch beim mehrfachen Lesen des bisher von mir Geschriebenen nicht, wo ich "die Matte verlassen" hätte), dann kann das auch nicht wirklich schaden und eine Eskalation kann ja eigentlich nur erfolgen, wenn sich eine Seite "richtig vergißt" und irgendwie unhöflich bzw. unsachlich wird.

Gerade zu den von mir angesprochenen Punkten bzgl. Deiner Änderungen würde ich schon gerne noch lesen, was Du Dir dabei genau gedacht hast - meinen Einwand bzgl. der Reihenfolge der FDTs in der Liste am Beginn des Bereiches kannst Du zwar ignorieren und Deinerseits keiner Antwort würdigen, das macht Deine Änderung aber nicht plausibler bzw. meinen Einwand nicht falsch. Ähnliches gilt für die Frage (in #62 nicht explizit gestellt, aber das hole ich hiermit gerne nach), ob man die Zusammenfassung zur "hasTag()"-Funktion nicht anders (ich kann auch gerne "besser" schreiben) hätte lösen können.

 

[PeterPawn]

Ausgehend von der hier festgestellten Übereinstimmung des "bootcore"-Kernels bei den bisher von AVM bekannten GRX350-Modellen (der Chipsatz heißt m.W. bei Intel "Intel(R) AnyWAN GRX350 Network Processor" - das GRX500, was AVM (bzw. wohl bereits Lantiq) da verwendet, hat m.E. nichts damit zu tun, daß es sich um einen GRX550 handeln würde, der auch nach der Intel-Website erst in diesem Quartal verfügbar wurde), habe ich noch einmal versucht zu recherchieren.

Es ist fast unmöglich, heutzutage genauere Informationen (oder gar Spezifikationen oder Handbücher) zum GRX350 zu finden ... aber an dieser Stelle hilft dann das "Gedächtnis" des Internets weiter:

https://web.archive.org/web/20150712022412/https://www.lantiq.com/grx

Dort findet sich dann eine frühere Presseinformation von Lantiq: https://web.archive.org/web/2015070...er-class-network-processing-for-home-gateway/

Leider hat die Wayback-Machine keine eigene Kopie des in diesem Satz verlinkten PDF-Files:

More information on TrueQoS, the dedicated security core and the hardware-enforced virtualization are available in a Media Backgrounder.

und so ist das (zumindest vorerst) "verloren".

Vielleicht hat es ja jemand zufällig noch in seinem Cache oder seinem Download-Verzeichnis - aus der Zeit, wo das noch nicht "Intel(R)" war und man noch Informationen finden konnte?

Mir geht es in erster Linie um diese "hardware-enforced virtualization" ... nach dem, was ich in der Zwischenzeit in der 7580 so gefunden habe, sieht das für mich wie eine Lösung mit einer einzelnen "virtuellen Maschine" auf dem Prozessor aus (bei AVM) und dieser "bootcore" wäre dabei der Hypervisor, der die Hardware ggf. zwischen mehreren solcher VMs sharen könnte - das ist zumindest die aktuelle (zuvor schon mal irgendwo hier geäußerte) Vermutung meinerseits.

Das wäre natürlich extrem spannend in Bezug auf die Möglichkeiten, diese Geräte um eigene Funktionen zu erweitern (z.B. einen OpenVPN-Router in einer VM) und dabei die AVM-Funktionen (bzw. die AVM-VM) gar nicht "anzufassen" - wobei das auch nur dann stimmen würde, wenn der Hypervisor für jede VM wenigstens irgendein Netzwerk-Interface zur Kommunikation untereinander bereitstellt (ansonsten müßte die AVM-VM sicherlich "wissen", daß es noch eine solche VPN-VM gibt)

Nachdem ich diesen "bootcore" am Beginn (vor ca. 9 Monaten) noch als den Bootloader angesehen hatte, was offenbar falsch war, suche ich "händeringend" nach ein paar Details zu diesem Prozessor. Bei Intel ist das leider alles im "Competence Center" verborgen und da kommt man nur gegen Bezahlung (und wohl auch nur mit einem NDA) weiter. Was mich etwas erstaunt, ist die Tatsache, daß es da auch fast keine Leaks gibt oder gab ... oder ich stelle mich nur zu blöd an, diese zu finden - sollte also jemand einen Tipp haben, nehme ich den gerne (auch per E-Mail, wenn das nichts für die Öffentlichkeit ist).

Jedenfalls kann man auch bei AVM in den Quellen einige der von Lantiq damals schon beschriebenen Feature finden ... das geht inzwischen bis zu einer TOE für das Offload-Processing beim Segmentieren und der Unterstützung für "jumbo frames" (wenn ich das richtig einschätze).

Wenn der "bootcore" tatsächlich "nur" der Hypervisor ist, würde das zumindest erklären, warum der relativ konstant und auch bei Modellen mit unterschiedlichen Funktionen identisch ist ... solange die konkreten Funktionen jeweils nur im AVM-Kernel umgesetzt werden, wäre eben die Hardware (hier geht es vermutlich nicht darum, welcher WLAN-Chipsatz verbaut ist, sondern mehr um Prozessor, DMA, Speicher, GPIO, Serielle, usw. - vielleicht wirklich noch den "Beschleuniger", wobei ich den eher als dedizierte Ressource für eine einzelne VM sehen würde, die dann die Netzwerk-Kommunikation komplett übernimmt) identisch und die Kommunikation zwischen VM und Hypervisor (und damit vermutlich auch zwischen zwei VMs über diesen Hypervisor) wird wohl per Mailbox oder etwas ähnlichem (natürlich über SHM oder Netzwerk, nicht über E-Mails ) erfolgen.

Das wäre dann auch eine Erklärung dafür, wo Teile des Speichers abgeblieben ist und warum der AVM-Kernel an eine Adresse 0x80500000 (also erst 5 MB nach dem Beginn des Speichers) geladen wird, obwohl doch in aller Regel irgendwelche Interrupt-Tabellen eher in den unteren (physikalischen) Speicherseiten liegen - hier übernimmt wohl der "bootcore" diese Steuerung der Hardware. Trotzdem scheint der Hypervisor der VM auch die unteren 5 MB "zu zeigen" (zumindest r/o) ... wobei das natürlich eine Virtualisierung sein kann und nicht mit dem physikalischen Speicher an dieser Stelle übereinstimmen muß - sonst wäre das ja eine etwas komische "Abschottung".

Die "klassischen" MIPS-Kriterien (für die Adressierung von KSEG0 bis KSEG2 bzw. KUSEG) dürften hier nicht mehr stimmen ... wie weit das schon dem "interaptiv"-Design und einem geänderten Memory-Management geschuldet ist oder "nur" EVA (hier mal kein AVM-Bootloader, sondern "Enhanced Virtual Addressing", mit dem mehr als 512 MB Speicher unter MIPS32 verwaltbar werden), weiß ich auch nicht. Das ist halt alles rein durch Lesen von (meist unvollständigen) Quellen auch recht langwierig und hat eine sehr flache Lernkurve mit entsprechendem Zeitbedarf.

 

[f666]

Hallo,

ich habe mir über eine Vertragsverlängerung bei 1&1 eine 7590 rausgelassen, die bald ankommen soll. Diese will ich in der Zukunft als meine Hauptbox verwenden. Da darauf auch VDR mit einem USB DVB-C Empfänger laufen soll, wäre Replace Kernel recht nützlich.

Ich habe mir sowohl den aktuellen Stand von Freetz als auch die Commit Historie zur 75x0 bzw. den GRX5 Modellen angesehen. Momentan ist Replace Kernel deaktiviert mit der Begründung des geänderten Bootloader Formats (config/ui/firmware.in).

Frage an @er13 und @PeterPawn:
Trifft das noch zu, also sind die Probleme mit dem Bootloader noch ungelöst? Oder liegt es nur noch an den fehlenden Kernel Quellen?
Hatte jemand erfolgreich einen eigenen Kernel auf einer 75x0 gestartet bekommen?

 

[tuxedonet]

Hatte jemand erfolgreich einen eigenen Kernel auf einer 75x0 gestartet bekommen?

um welche FW-Version/Kernel-Version geht es ?

für FB7580 06.88 siehe Thread :
https://www.ip-phone-forum.de/threads/freetz-trunk-7580_06-88-beta-mesh-bauen-revision-14326.295836/

fixed in r14327

 

[f666]

Blöd, dass gerade der Trac Server nicht tut, somit kann ich nicht in irgendwelchen Tickets nachforschen.

Im oben erwähnten Commit vom 1. Juli 2017 hat @er13 geschrieben:

 7580 mesh labor:

 * set kernel config area size to 160KB (seems to be the correct value, might also be 144KB)
 * TODO: 170-avm_kernel_config.patch has to be adjusted accordingly - as "replace kernel" is not available for labor firmwares we postpone it until the release firmware and the corresponding kernel sources are available
 * refs #2885, refs [http://www.ip-phone-forum.de/showthread.php?t=295836 this thread]


git-svn-id: http://svn.freetz.org/trunk@14327 f5190166-0702-4917-9039-51ec32eddaf5

Genau da steht, dass die Aktivierung von RK aufgeschoben wurde, wegen der Laborversion.

Bereits bei der Aufnahme der Boxen in r14111 war RK deaktiviert.
Später wurde in r14193 die Warnung eingefügt, dass RK wegen dem geänderten Bootloader Format nicht geht.

In r14118 wurde (laut Beschreibung) temporär avm_kernel_config_area deaktiviert um zumindest Kernelmodule erzeugen zu können. Das ist auch jetzt noch der Stand.

Was mich interessiert, ist ob RK für die 7590 06.9x deaktiviert ist, weil die Grundlagen fehlen, oder nur weil die aktuellen Sourcen fehlen.
Damit verwandt ist die Frage, ob jemand mal erfolgreich einen eigens erzeugten Kernel auf einer 7590 gebootet bekommen hat. Schließlich war ein 3/4 Jahr vergangen, als @PeterPawn den letzten Beitrag in diesem Thread geschrieben hatte und der ja ebenfalls GRX5 Boxen benutzt.

 

[PeterPawn]

Auf der 7580 hatte ich Mitte April 2017 (als die 06.81-Quellen verfügbar waren) mal einen selbstgemachten Kernel getestet, der war aber von Hand zusammenkopiert.

Nach der Auseinandersetzung mit @er13 (die im Okt. 2017 dann noch einmal einen Höhepunkt erreichte und seitdem ist komplette Funkstille) habe ich das nicht weiter verfolgt und sogar meinerseits angeregt (in Mails an @er13 und @RalfFriedl), daß Eugene das "avm_kernel_config" komplett aus dem YourFritz-Repo herauslöst bzw. seine eigene Variante selbst im Freetz-Repo verwaltet und es bei mir nur noch als "proof of concept" für die "frühe" 7490 stehen bleibt. @RalfFriedl wollte das dann noch als reine 64-Bit-Version umsetzen ... bisher ist es m.W. nicht im Freetz-Trunk angekommen.

Da ich wie gesagt "draußen" bin an dieser Stelle, hatte ich auf Deine erste "Anfrage" nicht geantwortet, weil ich dachte, die handelnden Personen würden sich dazu äußern.

Zur 7590 kann ich nichts sagen (auch wenn die Unterschiede m.E. gegen Null gehen sollte, ist ähnlich wie bei 6490 vs. 6590) und auch bei der 7580 habe ich meinerseits nur den ersten Kernel (also den "nicht-bootcore") selbst erstellt, weil der zweite eben bei den bisher verfügbaren GRX5-Firmwares identisch ist (bis inkl. des Bereichs bei "__avm_kernel_config", wo nur allgemeine Daten liegen, deren FDT-Vorlagen sogar in den OpenSource-Paketen enthalten sind) und man den nicht ändern müßte, selbst wenn man einen eigenen Kernel für das FRITZ!OS verwendet (auch da bestehen Meinungsverschiedenheiten zwischen Eugene und mir (schon seit #35, dritter Absatz von unten) und nicht nur bei der Frage, wie man das überhaupt am besten in den Build-Prozess integrieren sollte).

Wie weit die Freetz-Skripte zum Zusammenbau eines GRX5-Kernels inzwischen taugen, weiß ich nicht ... die Struktur ist irgendwo hier im Thread weiter vorne beschrieben (ab #33), nachdem mich @er13 auf die zusätzlichen Daten aufmerksam gemacht hatte. Das liest sich inzwischen sicherlich sehr unübersichtlich, weil @opto da einige seiner Beiträge entfernt hat und ich mich häufig darauf verlassen hatte, was unmittelbar vor einem Beitrag stand und dann auf entsprechende Zitate verzichtete - aber da müßtest Du (vielleicht) durch, wenn Du den eigenen Kernel von Hand zusammenbauen willst.

Wenn das (Freetz-)Skript zum Erstellen des Kernels irgendwie die beiden (gepackten) Images zu einer gemeinsamen Datei mit passendem Header zusammensetzt, könnte man natürlich auch das versuchen ... ich kenne aber den aktuellen Stand dort nicht und habe auch nicht mehr die Absicht, das zu ändern. Sorry ...

 

[f666]

OK, danke soweit.
Wenn ich die Box UND einige ruhige Minuten habe, werde ich mich mal dran machen, manuell einen eigenen Kernel zusammenzuschustern.
Falls der Bootcore wirklich alles durchreicht, sollte der für den DVB Empfang nicht im Weg sein und kann damit original bleiben.

 

[schumi20091]

Für mich fehlen in den Dateien der 7272, 7490 und der 7590 diese Dateien:
- der komplette Ordner "Openssl"
- die "libcrypto" Dateien

Wo bekommt man die passenden je für die Boxen her?

 

[PeterPawn]

@schumi20091:
Was genau meinst Du damit?

Die Quelltexte? Die müssen von AVM nicht geliefert werden, weil OpenSSL nicht unter GPL steht.

Wenn Du eigene Dateien bauen willst, nimm Freetz - oder erstelle Dir eine eigene Toolchain mit "buildroot" anhand der AVM-Quellen ... ist aber auch Arbeit, weil AVM das nur "rudimentär" anlegt und es nicht ohne eigene Anpassungen direkt läuft (mit der "gpl_compile_kernel.sh") bis zum "fertigen Image" (was zwar die GPL eigentlich fordert, aber das schert AVM ja - offensichtlich(!) - nicht wirklich).

 

[schumi20091]

brauche diese Dateien für einen Toolchain..

Der openssl Ordner ist jetzt passend erstellt, jetzt fehlen nur noch die "libcrypto" Dateien, wo bekommt man die her?