[Alternative PATCH 0/7] Alternatives Set zum OpenWrt 18.06
Tobias Klaus
tk at meskal.net
Di Aug 14 11:30:30 CEST 2018
Hey Tim,
so grundsätzlich gehe ich bei Adrians Argumentation mit. Das liegt, aber
vielleicht auch einfach daran, dass er iwie konstruktiver wirkt und ich seinen
Lösungsansatz prinzipiell erstmal eingängiger finde. (Ich hab beide Patchsets
nur überflogen.). Auch finde ich Michaels Einlassungen bezüglich der
Bastelfreundlichkeit als niederschwellige "Einstiegsdroge" nicht von der Hand
zu weisen.
Ansonsten habe ich hauptsächlich noch ein paar Kommentare und Fragen inline.
Am Montag, 13. August 2018, 07:49:27 CEST schrieb Tim Niemeyer:
> Hi
>
> Am 12. August 2018 22:47:39 MESZ schrieb mail at adrianschmutzler.de:
> >Hallo,
> >
> >trotz einiger Bedenkzeit bin ich immer noch der Meinung, dass uns diese
> >Lösung mehr Arbeit macht, als sie uns Vorteile bringt.
>
> da hast du jetzt die beiden patchsets verwechselt. In diesem geht es gerade
> darum Arbeit und Verwirrung zu sparen.
Also falls das lustig gemeint ist, fehlt mir gerade der Humor. Andernfalls
empfinde ich solche Kommentare in einer Diskussion, in der man sachlich auf
die Argumente des anderen eingehen möchte, irgendwie deplaziert.
> >Zunächst werden die Knoten wohl ohnehin nicht ganz "gleich", wir müssen
> >ja immer noch die unterschiedlichen Config-Files includen.
>
> Hm? Ne, innerhalb eines bsp ist es erstmal gleich.
>
> >Im Prinzip aber bauen wir hier eine Sonderwurst, die aus dem Konzept
> >von OpenWrt ausbricht.
>
> Die OpenWRT Menschen konnten nicht benennen, warum man das so nicht tun
> sollte. Das ist also kein Problem.
Wo hast du das nachgefragt? Auf deren Mailingliste habe ich nix gefunden.
> >Das führt dazu, dass wir immer nachdenken
> >müssen, ob wir das richtig machen und bei neuen Patches ggf.
> >Anpassungen notwendig werden. Das wäre u.U. gerechtfertigt, wenn sich
> >bei den Split-Targets relevante Nachteile ergeben würden. Die sehe ich
> >aber im Moment nicht.
>
> Die Nachteile eines neuen BSPs sind, dass wir zwei BSPs haben, die
> auseinander laufen werden, obwohl das unnötig ist. Weiter werden wit
> ständig aufpassen müssen nicht aus versehen eines der subtargets kaputt zu
> machen.
Dies .config hat doch eigentlich nur eine untergeordnete Rolle. Solange die
Abhängigkeiten der Freifunk-Pakete richtig modelliert sind, sollte das doch
eigentlich wenig Auswirkungen haben. Falls unterschiedliche BSPs SOOOO schlimm
sind, sollten wir uns vielleicht auch überlegen den Mechanismus ganz los zu
werden. Wer nutzt denn schon einen power pc ;-) ?
Schön ist es sicher nicht zwei BSPs zu pflegen. Aber die Erklärung warum das
_so_ aufwändig sein soll, wie du tust, bleibst du uns meiner Meinung nach
schuldig.
> >Nutzen wir die Split-Targets, müssen wir nur ein einziges Mal die bsps
> >aufteilen (= Copy/Paste) und dann die sysupgrade-Namen anpassen. Damit
>
> Stimmt nicht. Dein Patchset ist doch das perfekte Beispiel, es zeigt wie
> sehr das beim upgrade path verwirrt. Das ist einfach ein riesen Chaos, was
> vermeidbar ist.
Bei Adrians Argument gehe ich mit, deins scheint aber etwas verkürzt. Was
zeigt sich da wo? Die Namen haben sich (mal wieder) geändert. Was bedeutet das
für die Zukunft? Könntest du das erklären? Die Aufwandsabschätzung die Adrian
weiter unten liefert erschließt sich mir erstmal sehr gut.
> >ist die Sache erledigt und es fallen keine nachträglichen
> >Wartungsschritte mehr an (Ich verwende den Spaß ja jetzt schon seit
>
> In meinem Patch sind wir die Wartungsarbeiten los, ja. Bei deinem geht die
> Arbeit erst los.
Welche Wartungsarbeiten meinst du denn? Am Schluss sind wir immer von openwrt
abhängig. Und gerade wegen den volatilen Namen(was ich bisher als deinen
Hauptgrund für die Verwirrung, die jetzt herrscht) haben wir ja eben schon
eine entsprechende Abstraktion gebaut.
> >über 4 Monaten), da wir ja einfach OpenWrt so benutzen, wie es
>
> Es ist so nicht vorgesehen. Die OpenWRT Menschen wussten da doch selber
> nicht was sie tun. Ich hab doch extra nachgefragt.
Wieder die Frage wo?
> >nur, wenn man wirklich Geräte aus beiden Subtargets braucht (und halt
> >jeweils einmal pro halbem Jahr für ein Release).
> >
> >Bevor Tim und ich jetzt aber noch drei Mal die gleichen Meinungen
> >austauschen, ist das wohl ein Punkt, wo die Meinungen der anderen
> >Entwickler hilfreich wären. Dafür sind die beiden alternativen
> >Patchsets ja bestens geeignet.
>
> Im Grunde ja. Aber am Ende brauchen wir einen Konsens. Ich hab mir damals
> deine Patches angeschaut und eklatante Mängel gefunden. Zum einen an der
> Architektur zum anderen an den Probleme die diese Architektur nach sich
> ziehen. Es würde also Probleme in der Nachhaltigen Entwicklung bereiten.
> Alles nicht schlimm, dafür machen wir ja den ganzen review kram. Ich habe
> dich im Rahmen eines Konsens gebeten ein paar Dinge anzupassen. Ist aber
> leider nicht passiert. Also habe ich selber den Konsens gebaut. Und das
> hier ist das Ergebnis. Es ist eigentlich keine Alternative sondern die
> Weiterentwicklung deines Pachtssets, weil du leider nicht mehr weiter
> machen wolltest.
Nur weil etwas deiner Meinung nach "eklatant" ist, kann man trotzdem drüber
diskutieren und muss nicht blind deine Anmerkungen umsetzten. Genau das ist
hier passiert. Adrian hier jetzt eine Art Verweigerungshaltung vorzuwerfen,
trifft die Wahrheit meiner Meinung nach nicht.
Viele Grüße
Tobias
> >Beste Grüße
> >
> >Adrian
> >
> >> -----Original Message-----
> >> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf
> >> Of Tim Niemeyer
> >> Sent: Dienstag, 7. August 2018 07:09
> >> To: franken-dev at freifunk.net
> >> Subject: [Alternative PATCH 0/7] Alternatives Set zum OpenWrt 18.06
> >>
> >>
> >> Dieses Patchset basiert auf dem OpenWrt 18.06 v3 Patchset von Adrian,
> >> allerdings wird kein neues BSP eingeführt sondern tiny wird für
> >
> >ar71xx als
> >
> >> default genommen.
> >>
> >> Wir können so die Gleichheit der Knoten besser unter Kontrolle
> >
> >halten.
> >
> >> Das erspart uns langfristig viel Arbeit, weil Dinge auf einer Knoten
> >
> >Art gehen
> >
> >> und auf der anderen nicht.
> >>
> >> So lange wir die 4 MB Geräte unterstützen wollen müssen wir uns immer
> >
> >um
> >
> >> den Speicherplatz kümmern, da macht es quasi keinen Unterschied, ob
> >
> >wir
> >
> >> _alle_ Geräte auf 4 MB begrenzen oder nur ein paar.
> >>
> >> Mit dem Patch die Geräte alle auf tiny zu bauen, fahren wir
> >
> >langfristig
> >
> >> vermutlich auch keine Rückportierungsprobleme, weil es faktisch keine
> >
> >Rolle
> >
> >> spielt, ob ein Target für generic oder tiny entwickelt wurde.
> >>
> >> Wir sollten aber nochmal überlegen, ob es eventuell ungünstig für die
> >> Gateway Firmware wird. Desweiteren wäre zu überlegen, ob das wdr4900
> >> Target ggfs auch beschnitten werden sollte um das System weiter
> >> anzugleichen.
> >>
> >> Hinweis: Da scheint irgendwo ein parallel-build Fehler zu sein. :(
> >
> >Ich konnte
> >
> >> im ersten Durchlauf nur mit einem Job sauber bauen, ansonsten musste
> >
> >ich
> >
> >> immer zweimal bauen. Der MR3020 baut immer noch nicht.
> >>
> >> Tim
> >>
> >> Adrian Schmutzler (4):
> >> OpenWRT: Update OpenWrt, packages and routing to openwrt-18.06
> >> fff-boardname: Fix changed board name of WDR4900v1
> >> fff-firewall: Fix match in ip6tables and add dependencies
> >> root_file_system: Remove sysctl.conf
> >>
> >> Tim Niemeyer (3):
> >> OpenWrt: Use the tiny target and update names
> >> fff-sysupgrade: Update sysupgrade.sh to support openwrt-18.06
> >> OpenWrt: Save space
> >>
> >> bsp/ar71xx/.config | 139 ++--
> >> bsp/board_ar71xx.bsp | 68 +-
> >> bsp/board_wdr4900.bsp | 2 +-
> >> bsp/default/root_file_system/etc/sysctl.conf | 1 -
> >> .../openwrt/0001-sysupgrade-no-config-save.patch | 12 +-
> >> build_patches/openwrt/0002-set-root-password.patch | 6 +-
> >> .../openwrt/0003-ntpd-host-as-string.patch | 6 +-
> >> ...tats.patch => 0004-ar71xx-4.9-l2tp-stats.patch} | 12 +-
> >
> >.../0005-allow-
> >
> >> building-all-devives-as-tiny.patch | 28 +
> >
> >...ils-tplink-safeloader-support-
> >
> >> strings-as-.patch | 164 -----
> >
> >...1xx-add-support-for-TP-Link-Archer-C25-
> >
> >> v1.patch | 501 ---------------
> >
> >...ils-tplink-safeloader-add-TP-Link-Archer-.patch
> >
> >> | 114 ---- ...mware-update-qca9887-firmware-to-10.2.4-1.patch | 41
> >
> >-- ...ils-
> >
> >> mktplinkfw-rework-combined-image-opti.patch | 264 --------
> >
> >...mktplinkfw-
> >
> >> combined-command-to-image-comm.patch | 103 --- ...13-ar71xx-add-
> >> support-for-TL-WR1043N-v5.0.patch | 697 ---------------------
> >
> >...do-not-apply-
> >
> >> broken-power-limits-with-ATH.patch | 173 -----
> >
> >...-remove-bs-partition-ro-
> >
> >> flag-for-UniFi-AC.patch | 36 --
> >
> >...ort-interface-IDs-with-more-than-two-
> >
> >> digi.patch | 35 --
> >>
> >> buildscript | 12 +-
> >> .../files/etc/uci-defaults/50-fff-boardname | 3 +
> >> src/packages/fff/fff-firewall/Makefile | 5 +-
> >> .../files/usr/lib/firewall.d/20-filter-ssh | 4 +-
> >> .../fff/fff-sysupgrade/files/etc/sysupgrade.sh | 14 +-
> >> 24 files changed, 172 insertions(+), 2268 deletions(-) delete mode
> >
> >100644
> >
> >> bsp/default/root_file_system/etc/sysctl.conf
> >>
> >> rename build_patches/openwrt/{0004-ar71xx-4.4-l2tp-stats.patch =>
> >
> >0004-
> >
> >> ar71xx-4.9-l2tp-stats.patch} (83%) create mode 100644
> >> build_patches/openwrt/0005-allow-building-all-devives-as-tiny.patch
> >>
> >> delete mode 100644 build_patches/openwrt/0005-firmware-utils-tplink-
> >>
> >> safeloader-support-strings-as-.patch
> >>
> >> delete mode 100644
> >
> >build_patches/openwrt/0006-ar71xx-add-support-for-
> >
> >> TP-Link-Archer-C25-v1.patch
> >>
> >> delete mode 100644 build_patches/openwrt/0007-firmware-utils-tplink-
> >>
> >> safeloader-add-TP-Link-Archer-.patch
> >>
> >> delete mode 100644
> >
> >build_patches/openwrt/0008-ath10k-firmware-update-
> >
> >> qca9887-firmware-to-10.2.4-1.patch
> >>
> >> delete mode 100644 build_patches/openwrt/0011-firmware-utils-
> >>
> >> mktplinkfw-rework-combined-image-opti.patch
> >>
> >> delete mode 100644 build_patches/openwrt/0012-build-move-mktplinkfw-
> >>
> >> combined-command-to-image-comm.patch
> >>
> >> delete mode 100644
> >
> >build_patches/openwrt/0013-ar71xx-add-support-for-
> >
> >> TL-WR1043N-v5.0.patch
> >>
> >> delete mode 100644
> >
> >build_patches/openwrt/0020-Revert-ath-do-not-apply-
> >
> >> broken-power-limits-with-ATH.patch
> >>
> >> delete mode 100644 build_patches/openwrt/0031-ar71xx-remove-bs-
> >>
> >> partition-ro-flag-for-UniFi-AC.patch
> >>
> >> delete mode 100644
> >
> >build_patches/routing/0001-alfred-Support-interface-
> >
> >> IDs-with-more-than-two-digi.patch
> >>
> >> --
> >> 2.11.0
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 833 bytes
Beschreibung: This is a digitally signed message part.
URL : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20180814/1ab07ef6/attachment.sig>
Mehr Informationen über die Mailingliste franken-dev