gui_bootmanager: add support for "fixed branding"-approach used in Freetz #16
Conversation
…eetz Signed-off-by: Eugene Rudoy <gene.devel@gmail.com>
|
Warum verfolgt Freetz hier überhaupt einen anderen Ansatz bei der Änderung? Welcher Vorteil ergibt sich genau aus dem Vorgehen in Freetz? Original: ##########################################################################################
## OEM Ermitteln
##########################################################################################
OEM_tmp=`cat $CONFIG_ENVIRONMENT_PATH/firmware_version`
if [ -z "${OEM_tmp}" ] ; then
OEM_tmp=$CONFIG_OEM_DEFAULT
fi
OEM=${OEM_tmp%,*}
OEM_DEFAULT_INDEX=${OEM_tmp#*,}
if [ "$OEM_DEFAULT_INDEX" = "$OEM" ] ; then
OEM_DEFAULT_INDEX=""
fi
export OEM_DEFAULT_INDEX
export OEMImmer wenn ich im IPPF diesen Weg der Änderung des Brandings als Möglichkeit beschrieben habe: https://www.ip-phone-forum.de/threads/7590-branding-%C3%A4ndern-freetz-flashen.298603/#post-2265245 , dann habe ich (auch wegen der Eindeutigkeit der Fundstelle - weil es nur eine Zeile gibt, die ein In meinen Augen macht es die zusätzliche Behandlung in den folgenden Zeilen nur komplizierter, dem Flow zu folgen, wenn man die Ersetzung in der Zeile direkt nach den Kommentaren vornimmt, wie Du es dann in Freetz übernommen hast (was ich zuvor gar nicht gesehen hatte, zumindest nicht die tatsächliche Umsetzung). In meiner E-Mail zu diesem Patch in Freetz schrieb ich auch noch an Dich: Solange eine Box zu denen gehört, wo das dauerhafte Überschreiben von Ich hatte mich damals (als ich den Vorschlag machte) vergewissert, daß es in der Firmware keine anderen Stellen mit "firmware_version" gab ( Der ganze andere Quatsch von AVM wird (wenn man es analysiert, was da gemacht wird) ohnehin nicht verarbeitet, wenn man in dieser Zeile nicht aus dem Environment liest, sondern ein einzelnes Branding (das dann auch keinen DEFAULT_INDEX hat, wenn man dem Patch in Freetz folgt) fest einträgt. Theoretisch könnte man (wenn man die Änderung nicht so klein wie möglich halten will) sogar alle Zeilen vor den beiden Ich verstehe also nicht, warum die Änderung in Freetz an einer anderen Stelle erfolgt (vielleicht sehe ich ja auch den plausiblen Grund für eine solche Entscheidung nicht und Du kannst es begründen) und warum daraus jetzt noch eine Änderung am Zumal ich das eben (Begründung siehe oben) auch noch logischer und leichter zu verfolgen fände, weil man bei der Ansicht des Wer die Zeilen davor dann zu kompliziert findet, wirft sie einfach gleich mit raus beim Patchen. In |
|
Na ja, die Logik ist eigentlich ganz primitiv:
Bei der in Freetz umgesetzten Logik handelt es sich auch um einen Einzeiler oder in deiner Sprache "die kleinste mögliche Veränderung der originalen Firmware" - das Auslesen wird durch einen fixen Wert ersetzt. Ich habe nicht verlangt, dass modfs in irgendeine Weise angepasst wird (dein letzter Absatz). Ich habe lediglich einen Patch submittet, der den Bootmanager um die in Freetz verwendete Logik erweitert. |
|
Meine - dagegen gesetzte - Logik ist es: Ändere die Stelle, wo etwas wirklich seine Auswirkungen zeitigt ... dann kann man den Rest auch weglassen (aber das habe ich oben ja schon versucht zu erläutern) und wenn jemand sich im Detail damit befassen will, was da tatsächlich geschieht (code review), sieht er es auf den ersten Blick und nicht erst nach der Analyse von neun weiteren Code-Zeilen. Mein Änderungsvorschlag setzt bei den Auswirkungen an und Deine Implementierung in Freetz bei den "Eingabewerten" - die durch nachfolgende Verarbeitung und Umformung zumindest potentiell noch einer Veränderung unterworfen sein können und wo das Ergebnis des Patches somit von weiterem Code zwischen der geänderten Stelle und dem "Wirk-Statement" beeinflußt werden kann oder wenigstens könnte. BTW ... ich habe auch nie behauptet, daß Du von mir eine Änderung in Meine Frage zielte ja deutlich auf den funktionellen Unterschied zwischen der meinerseits angesprochenen/vorgeschlagenen Implementierung (siehe meine E-Mail mit Datum: Thu, 23 Aug 2018 22:48:34 +0200) in der Ich hatte die darauf folgende Änderung in Freetz zwar zur Kenntnis genommen, mich aber gar nicht in den Deine eigene Entscheidung ... aber ich habe in den Das Argument, daß man da ändert, wo es am deutlichsten und am leichtesten nachvollziehbar ist, wäre zu entkräften - i.V.m. dem optionalen Entfernen der dann ohnehin überflüssigen Zeilen. Die korrekte Behandlung eines Dabei muß man den AVM-Code dann schon noch anschauen, wenn man verstehen will, was da eigentlich passiert - wenn jetzt hier auf einmal Argumente in der Richtung:
kommen, wo Du ansonsten immer damit argumentierst, daß mit so mancher "stilistischen Änderung" ein "review" dann (zumindest für Dich) leichter wäre als mit dem originalen Code irgendeines Autors, verblüfft mich das auch einigermaßen - warum auf einmal diese geänderte Haltung, daß das niemand ansehen und verstehen müsse? Wenn Du also gute und nachvollziehbare Gründe dafür gehabt haben solltest, die Implementierung in Freetz eben gerade nicht durch die Änderung von Nur dann, wenn AVM die Variable irgendwie anders als Das entscheidende Statement für das durch den Patch geänderte Verhalten der Firmware ist das Die Wahrscheinlichkeit, daß AVM die Wenn AVM in den Zeilen vor dem Es ist sicherlich unverkennbar, daß ich noch nicht überzeugt bin und die Notwendigkeit des hier vorgeschlagenen Patches u.a. deshalb nicht erkennen kann, weil mir nicht klar wird, warum Du in Freetz genau diesen Weg der Änderung eingeschlagen hast - meine Argumente, warum ich diesen für weniger geeignet halte (ich verzichte ganz bewußt auf die Bewertung schlechter, weil ich ja auch den Standpunkt vertrete, daß es immer mehrere Wege einer Umsetzung gibt und jede ihre Vor- und Nachteile hat, die man eben gegeneinander abwägen muß), habe ich vorgetragen. Es wäre jetzt an Dir, diese zu entkräften und zu zeigen, daß es eben nicht nur das "Andersmachen" war, was Dich hier bei Deinen Überlegungen im Vorfeld zu dieser Änderung geleitet hat. Das Argument "ich ändere da, wo es ansonsten ausgelesen würde" habe ich zur Kenntnis genommen und ihm die potentielle Umformung des Wertes vor dem Export entgegengestellt, die mit höherer Wahrscheinlichkeit zu unerwünschten Effekten führen kann, als die Änderung direkt beim Export. Die anderen zwei Punkte in Deiner Begründung (hier wäre es auch nett, wenn Du künftig gleich ein oder zwei Worte zu den Gründen für den Vorschlag verlieren könntest - das macht es nicht nur mir leichter, den Vorschlag einzuordnen, es hilft auch Dritten eher zu verstehen, worum es da überhaupt geht) kann ich nicht nachvollziehen. |
|
Sorry, ich kann deinen Argumenten nicht folgen bzw. diese nicht nachvollziehen. Warum in aller Welt muss ich mich mit den Zeilen nach dem Auslesen aus dem Environment beschäftigen? Diese kann ich komplett ignorieren, es ist mir egal, was und wie AVM da macht - ich versuche sich nicht mal zu verstehen. Ob ich den Wert direkt ins Environment reinschreibe (auf den Boxen, auf denen es geht) oder beim Auslesen so tue, als würde genau der Wert drin stehen, ist doch genau das gleiche. Beim direkten Reinschreiben ins Environment habe ich mich mit diesen Zeilen doch nicht beschäftigen müssen, warum auf einmal jetzt? Entscheidend ist, dass alle Auslese-Stellen erwischt werden (das trifft zu, es gibt genau eine) und dass der verwendete fixe Wert ein sinnvoller Wert ist, einer, den ich (auf einer anderen Box, auf einer auf der es geht) direkt ins Environment reinschreiben könnte. Auch deine Gegenargumentation gegen "gewappnet" kann ich nicht nachvollziehen. Es ist mir egal, was AVM nach dem Auslesen macht und wie die Änderungen an der Stelle ausschauen könnten - solange alle Auslese-Stellen erwischt sind und ein sinnvoller Wert als fixer Wert verwendet wird, kann nichts passieren, denn es ist das gleiche als würde dieser Wert in dem Environment stehen. Am Ende sei gesagt, beide Lösungen haben ihre Dasein Berechtigungen. Ich fand "suggeriere es an der Auslese-Stelle" besser. Der kleine Vorteil meiner Lösung besteht darüberhinaus darin, dass man tatsächlich fixe Werte mit einem OEM_DEFAULT_INDEX setzen kann und diese auch korrekt verarbeitet werden. Dein Ansatz lässt dies nicht zu. p.s. Ich finde es überraschend, wie viel Aufwand du ins "Schlecht-Reden" meines Ansatzes investierst. Wenn du den Pull-Request nicht übernehmen möchtest, kann ich damit leben. Du musst nicht viel argumentieren. p.p.s. Den letzten Absatz aus Comment 1, konkret den allerletzten Satz von diesem "habe deshalb nicht die Absicht, das dort zu entfernen", habe ich so aufgefasst, als hättest du mich so verstanden, als würde ich dich (indirekt) zum Anpassen/zum Enrfernen deines Codes auffordern. Das "entfernen" bezieht sich jedoch vermutlich auf die "Zeilen" - dann habe ich dich missverstanden. |
|
Ich verstehe nicht, warum es in Freetz überhaupt eine andere Lösung gibt für das Setzen eines festen "Brandings" und daher möchte ich diesen Pull-Request nicht übernehmen. Wenn Du auf dem "Andersmachen" in Freetz beharren möchtest, dann kannst Du problemlos auch die Zeile aus diesem PR dazupatchen, wenn Du das tatsächlich als notwendig erachtest. Daß mein Vorschlag sowohl in der E-Mail-Kommunikation mit Dir als auch in diversen Beiträgen im IPPF anders aussah (und zwar so, wie ihn der Ich kann und werde aber bei weiteren Änderungen an diesem Skript keine Rücksicht auf diese Unterschiede nehmen, weil sie ohne jede Notwendigkeit und damit mutwilig hervorgerufen werden - das gilt dann auch für die Fehlersuche in dieser abgewandelten Version, so eine solche erforderlich werden sollte. PS: Das, was Du als "Schlechtreden" Deines Ansatzes zu verstehen geruhtest, ist der Versuch einer Argumentation (es ist mir schon klar, daß Dir das eigentlich wesensfremd ist), warum ich die Änderung an der Da ich aber nicht erkennen kann, aus welchem Grund Du meine Argumente "nicht nachvollziehen" kannst (auf Gegenargumente verzichtest Du ja und erklärst nur, daß Dich alle anderen Aspekte bei diesem Patch gar nicht interessieren), erübrigt sich tatsächlich jede weitere Diskussion und ich halte es für geboten, hier meinerseits zu schließen. |
|
Sorry, Peter, der folgende Satz aus meiner Antwort Ob ich den Wert direkt ins Environment reinschreibe (auf den Boxen, auf denen es geht) oder beim Auslesen so tue, als würde genau der Wert drin stehen, ist doch genau das gleiche. ist doch genau die Begründung/die Argumentation, warum es mich gar nicht interessiert, was AVM in den Zeilen nach dem Auslesen macht. Und warum mein Ansatz durchaus gegen potentielle Änderungen an der Stelle gewappnet ist. Das hast du doch beides in Frage gestellt. Edit: oder anders formuliert. Haben mich die Zeilen nach dem Auslesen zu interessieren, wenn ich den Wert direkt, persistent ins Urlader-Environment reinschreibe? Bin ich gegen die potentielle Änderungen von AVM an der Stelle gewappnet, wenn ich es direkt reinschreibe? Meine Antworten auf die beiden Fragen lauten: nein und ja. Du versuchst doch zu argumentieren, die haben mich zu interessieren: Dabei muß man den AVM-Code dann schon noch anschauen, wenn man verstehen will, was da eigentlich passiert und ein "gewappnet" ist für dich nicht erkennbar (warum übrigens gegen "die letzte Zeile" - ich habe nie etwas in Bezug auf die letzte Zeile gesagt) ein "gewappnet" gegen künftige Änderungen der letzten Zeile (EDIT: durch AVM) im oben gezeigten Ausschnitt kann ich nämlich nicht nachvollziehen - erst recht nicht, warum das bei einer Änderung der letzten Zeile durch den Patch nicht (oder mit geringerer Wahrscheinlichkeit) der Fall sein sollte. |
|
Nein, das stimmt eben nicht und das hatten wir als Argumentation auch schon in der E-Mail. Wenn Du tatsächlich den gewünschten Wert ins (EDIT: Urlader-)Environment schreibst, nachdem das System diese Schreibzugriffe gestattet und die Werte dort "zusammengebaut" hat (das "prom_getenv()" arbeitet bei verschiedenen Modellen da durchaus auch verschieden), dann ist das ein - absolut unnötiger - Schreibzugriff auf das TFFS und - wenn's schlecht läuft - tatsächlich sogar ein gesonderter, der nicht gemeinsam mit anderen (dank Caching) ausgeführt wird (und zwar bei jedem Bootvorgang). Wenn sich jemand den Patch ansieht und den ggf. auf eine von AVM geänderte Firmware anpassen will oder muß, ist es allemal besser, wenn er dabei feststellt, daß der Patch die Stelle ändert, wo es am Ende auch entsprechende Auswirkungen hat und das ist das "export" - bei allem anderen davor kann das nach (theoretischen) Änderungen durch AVM noch eine geänderte Logik ergeben, die man dann zusätzlich überprüfen muß. Den gesamten Teil "OEM ermitteln" könnte man auf die zwei "export"-Zeilen eindampfen (wenn man den Wert ohnehin fest vorgeben will), dann würde es noch übersichtlicher und die vorliegende Implementierung in Freetz ermöglicht es eben genau auch nicht, einen (ohnehin eher ungebräuchlichen) OEM_DEFAULT_INDEX zu verwenden, weil dann das Branding als "nicht unterstützt" angesehen würde in der "for"-Schleife: https://github.com/Freetz/freetz/blob/master/patches/scripts/101-enforce_branding_via_rc.conf.sh#L3 - das kann also als Begründung für vorher angestellte Überlegungen auch nicht greifen. Ich habe mit den ganzen Worten versucht, Dir eine Gelegenheit zu bieten, eine plausible Erklärung abzugeben, warum Du in Freetz an genau dieser Stelle ändern willst oder mußt. Machst Du das nicht und änderst die Stelle aus meinen Vorschlägen (und die sind eben nicht neu, was ich versucht habe mit den Links zu "beweisen"), braucht es den Patch gar nicht erst, weil dann die Änderung in Freetz ebenfalls auf dem Wege erfolgt, den ich in "modfs" realisiert habe und den ich - seit langem - im IPPF für diesen Fall empfehle. Wenn Du triftige Gründe dafür hast, das unbedingt in dieser Zeile ändern zu müssen und nicht an der Stelle, die ich - und zwar auch nach einigem Überlegen, was ich schon in der E-Mail vom 23.08. begründet hatte - ausgewählt habe, dann sollten diese ja auch überzeugend darzulegen sein und da sehe ich dann solche Sätze:
oder auch
nicht wirklich als Versuch einer Argumentation an. Auch wenn es Dich persönlich nicht interessieren mag, muß man auch die Interessen anderer berücksichtigen können und solange Du keinen wirklich triftigen Grund dafür hast, die Änderung nicht an der von mir empfohlenen Stelle, sondern an einer anderen auszuführen, ist das in meinen Augen ein vermeidbarer Unterschied, der ebenso durch die Änderung des Patches in Freetz behoben werden kann und wo es keiner Änderung des |
|
Mein Gott, mit "ins Environment reinschreiben (auf den Boxen, auf denen es geht)" ist das persistente Reinschreiben in die Urlader-Partition gemeint, das gleiche, was man über das Setzen über den Bootloader erreichen kann. Oder andersrum, mit "ins Environment reinschreiben" ist der alte Ansatz gemeint, der, den man verwendet hat, bevor AVM angefangen hat, die Bootloader-Versionen zu verwenden, die das persistente Verändern des Wertes verhindern. Und die von dir zitierten Abschnitte sind sehr wohl die Argumente. Steht der Wert in dem Environment (weil es z.B. eine Original-Box ist oder weil man es über den Bootloader da rein geschrieben hat) ist es genau das gleiche als würde man beim Auslesen suggerieren, der Wert stünde dadrin. |
|
Nur noch zur Info ... wenn ich von "letzte Zeile" schreibe, beziehe ich mich auf den oben von mir gezeigten Ausschnitt aus der "rc.conf" - weil Du irgendwo in den nachträglichen Änderungen wohl die Frage danach gestellt hast. Aber ich kann meine Frage auch durchaus kürzer und prägnanter (dann vielleicht nicht mehr so "freundlich") formulieren: Welcher Grund genau macht es für Dich (bzw. für Freetz) jetzt unumgänglich, an einer anderen Stelle als dem |
Auch diese Aussage ist interessant. Ich hätte den Patch aus diesem Pull-Request gleich in Freetz veröffentlichen können. Habe aber bewusst drauf verzichtet und habe es erst dir zukommen lassen, um dir entgegen zu kommen und das von dir an den anderen Stellen gewünschte "erst Diskutieren" zu ermöglichen. Ergebnis - egal, wie ich es mache - bist du nicht zufrieden ;-) |
|
Du willst mir doch nicht wirklich ernsthaft einreden, daß Du die alternative Lösung, den Patch in Freetz eben so vorzunehmen, wie ich es vorgeschlagen hatte, nicht selbst erkannt hättest? Jetzt wird es wirklich albern ... irgendetwas muß Dich ja trotzdem veranlaßt haben, das dann hier als Vorschlag zu unterbreiten. Vielleicht willst Du ja doch noch begründen, warum Du in Freetz den Patch anders umsetzen mußtest, als ich es ursprünglich vorgeschlagen habe (und zwar nicht nur in der Mail an Dich)? |
Den Satz verstehe ich (sprachlich) nicht - "die alternative Lösung, den Patch in Freetz eben so vorzunehmen, wie ich es vorgeschlagen hatte" - hmm?
Ich fand es intuitiver. "Suggeriere man hätte den Wert ausgelesen" ist für mich intuitiver. Und das mit dem Entfallen der Notwendigkeit zu verstehen, was da alles rum herum geschieht. |
|
Über die sprachlichen Schwierigkeiten kann ich Dir gerne hinweghelfen: Ich bin nicht bereit zu glauben, daß Du tatsächlich nicht in der Lage gewesen wärest, den Patch in Freetz so zu ändern, daß eine Änderung am
Das ist also wieder mal kein objektiv nachvollziehbarer Grund, sondern eher "ein Gefühl" bzw. ein "ich fand ..." - dagegen kann man dann auch nur noch ein eigenes "ich finde" setzen und das sieht dann am Ende so aus: ##########################################################################################
## OEM Ermitteln
##########################################################################################
export OEM_DEFAULT_INDEX
export OEM=avmIntuitiver und übersichtlicher geht es kaum noch und es ist auch simpel zu ändern, weil mit "OEM ermitteln" und "export OEM" die notwendigen Ankerzeilen vorhanden sind, um alles dazwischen zu entfernen. Auch hier gibt es nichts anderes mehr "rundherum", was man verstehen müßte. Dieser Fall würde dann aber tatsächlich auch vom derzeitigen Stand des |
|
Um die Lösung aus deiner letzten Antwort umzusetzen, muss man doch davor verstanden haben, was alles rum herum geschieht und dass dieses "rum herum" tatsächlich komplett entfernt werden kann. Mein Ansatz ist doch (das von dir unbeliebte) "es interessiert mich erst gar nicht", denn ich suggeriere "der Wert stünde drin". Wenn der AVM-Code für den tatsächlich in dem Environment stehenden Wert funktioniert, dann wird er auch für den suggeriere-Fall funktionieren. Mich interessiert (im Sinnde, nicht von Bedeutung) die Nachvollziehbarkeit der Stelle, an der der Eingriff erfolgt, gar nicht. |
|
Eine Software zu patchen, deren Funktionsweise man nicht verstanden oder nicht untersucht hat, weil es "einen nicht interessiert", ist ein Vorgehen, was wohl mit dem "allgemeinen Verständnis" oder mit "best practices" nur schwer in Kongruenz zu bringen ist ... und es steht in eklatantem Widerspruch zu Äußerungen, die Du sonst so tätigst:
Quelle: https://www.ip-phone-forum.de/threads/fehlende-bestandteile-im-opensource-paket-von-avm.287995/page-3#post-2215988 - und da kann man noch jede Menge andere Argumente Deinerseits nachlesen, warum Du bei anderen Gelegenheiten den Code genau deswegen wieder ändern mußtest, weil Du (obwohl es Dich gar nicht tangieren müßte) unbedingt verstehen mußt, was da genau passiert. Offenbar ist das ziemlich selektiv, wann Du Dich für die eine Position (ich muß alles verstehen können und will das auch) und wann für die andere (interessiert mich nicht die Bohne, Hauptsache das Ergebnis stimmt) entscheidest ... man könnte den Eindruck gewinnen, daß es immer darauf ankommt, wie es Dir gerade am besten in den Kram paßt. Aber wir sollten aufhören ... ich sehe nicht, daß wir hier vorwärts kommen werden und Du hast Deine Entscheidung getroffen, daß Du bei Deiner Implementierung bleiben willst (der Commit dokumentiert das). Ich will nur noch mal festhalten, daß Du das keineswegs so umsetzen mußtest, wie Du es getan hast ... das ist erneut nur das Ergebnis, weil Du es so machen wolltest. |
No description provided.