Um der build prozess zu beschleunigen, würde ich gerne ganz alte Router, die noch nie gesehen wurden aus den targets rausschmeißen.
Als Einstieg würde ich erstmal alle devices, die wir nicht in unserer Community haben aus dem tiny-target rausschmeißen, da wir sowieso nur noch die sysupgrades bauen für die deprecated devices.
Kann ich die einfach in der targets config löschen?
Das hier wäre mein Patch:
From 3a7826cf311531b1130fc01cad4a59db86ba7da7 Mon Sep 17 00:00:00 2001
From: Ruben Barkow-Kuder <github@r.z11.de>
Date: Sat, 14 May 2022 00:58:46 +0200
Subject: [PATCH] remove tiny-targets, we don't need any more
---
targets/ar71xx-tiny | 66 ---------------------------------------------
1 file changed, 66 deletions(-)
diff --git a/targets/ar71xx-tiny b/targets/ar71xx-tiny
index a0a8d510..8ee241cc 100644
--- a/targets/ar71xx-tiny
+++ b/targets/ar71xx-tiny
@@ -16,13 +16,6 @@ defaults {
}
--- D-Link
-
-device('d-link-dir-615-rev-c1', 'dir-615-c1', {
- profile = 'DIR615C1',
-})
-
-
-- TP-Link
local tplink_region_suffix = ''
@@ -30,41 +23,12 @@ if (env.GLUON_REGION or '') ~= '' then
tplink_region_suffix = '-' .. env.GLUON_REGION
end
-device('tp-link-tl-wa701n-nd-v1', 'tl-wa701nd-v1')
-device('tp-link-tl-wa701n-nd-v2', 'tl-wa701nd-v2')
-
-device('tp-link-tl-wa7210n-v2', 'tl-wa7210n-v2')
-device('tp-link-tl-wa7510n-v1', 'tl-wa7510n-v1')
-
-device('tp-link-tl-wr703n-v1', 'tl-wr703n-v1')
-
-device('tp-link-tl-wr710n-v2', 'tl-wr710n-v2')
-
-device('tp-link-tl-wr740n-nd-v1', 'tl-wr740n-v1')
-device('tp-link-tl-wr740n-nd-v3', 'tl-wr740n-v3')
device('tp-link-tl-wr740n-nd-v4', 'tl-wr740n-v4')
-device('tp-link-tl-wr740n-nd-v5', 'tl-wr740n-v5')
-device('tp-link-tl-wr741n-nd-v1', 'tl-wr741nd-v1')
-device('tp-link-tl-wr741n-nd-v2', 'tl-wr741nd-v2')
device('tp-link-tl-wr741n-nd-v4', 'tl-wr741nd-v4')
-device('tp-link-tl-wr741n-nd-v5', 'tl-wr741nd-v5')
-
-device('tp-link-tl-wr743n-nd-v1', 'tl-wr743nd-v1')
-device('tp-link-tl-wr743n-nd-v2', 'tl-wr743nd-v2')
-device('tp-link-tl-wa801n-nd-v1', 'tl-wa801nd-v1')
-device('tp-link-tl-wa801n-nd-v2', 'tl-wa801nd-v2')
device('tp-link-tl-wa801n-nd-v3', 'tl-wa801nd-v3')
-device('tp-link-tl-wr802n-v1', 'tl-wr802n-v1', {
- broken = true, -- untested
-})
-
-device('tp-link-tl-wr840n-v2', 'tl-wr840n-v2')
-
-device('tp-link-tl-wr841n-nd-v3', 'tl-wr841-v3')
-device('tp-link-tl-wr841n-nd-v5', 'tl-wr841-v5')
device('tp-link-tl-wr841n-nd-v7', 'tl-wr841-v7')
device('tp-link-tl-wr841n-nd-v8', 'tl-wr841-v8')
device('tp-link-tl-wr841n-nd-v9', 'tl-wr841-v9')
@@ -76,18 +40,7 @@ device('tp-link-tl-wr841n-nd-v12', 'tl-wr841-v12', {
factory = '-squashfs-factory' .. tplink_region_suffix,
})
-device('tp-link-tl-wr843n-nd-v1', 'tl-wr843nd-v1')
-
device('tp-link-tl-wr941n-nd-v2', 'tl-wr941nd-v2')
-device('tp-link-tl-wr941n-nd-v3', 'tl-wr941nd-v3')
-
-device('tp-link-tl-wr941n-nd-v4', 'tl-wr941nd-v4', {
- aliases = {'tp-link-tl-wr940n-v1'},
-})
-
-device('tp-link-tl-wr941n-nd-v5', 'tl-wr941nd-v5', {
- aliases = {'tp-link-tl-wr940n-v2'},
-})
device('tp-link-tl-wr941n-nd-v6', 'tl-wr941nd-v6', {
aliases = {'tp-link-tl-wr940n-v3'},
@@ -102,32 +55,13 @@ device('tp-link-tl-wr940n-v6', 'tl-wr940n-v6', {
factory = '-squashfs-factory' .. tplink_region_suffix,
})
-device('tp-link-tl-wa730re-v1', 'tl-wa730re-v1')
-
-device('tp-link-tl-wa750re-v1', 'tl-wa750re-v1')
-
-device('tp-link-tl-wa830re-v1', 'tl-wa830re-v1')
-device('tp-link-tl-wa830re-v2', 'tl-wa830re-v2')
-
device('tp-link-tl-wa850re-v1', 'tl-wa850re-v1')
-device('tp-link-tl-wa860re-v1', 'tl-wa860re-v1')
-
-device('tp-link-tl-wa901n-nd-v1', 'tl-wa901nd-v1')
-device('tp-link-tl-wa901n-nd-v2', 'tl-wa901nd-v2')
device('tp-link-tl-wa901n-nd-v3', 'tl-wa901nd-v3')
-device('tp-link-tl-wa901n-nd-v4', 'tl-wa901nd-v4')
device('tp-link-tl-wa901n-nd-v5', 'tl-wa901nd-v5')
-device('tp-link-tl-mr13u-v1', 'tl-mr13u-v1')
-
device('tp-link-tl-mr3020-v1', 'tl-mr3020-v1')
-device('tp-link-tl-mr3040-v1', 'tl-mr3040-v1')
-device('tp-link-tl-mr3040-v2', 'tl-mr3040-v2')
-
device('tp-link-tl-mr3220-v1', 'tl-mr3220-v1')
-device('tp-link-tl-mr3220-v2', 'tl-mr3220-v2')
-device('tp-link-tl-mr3420-v1', 'tl-mr3420-v1')
device('tp-link-tl-mr3420-v2', 'tl-mr3420-v2')
--
2.34.1ja,wenn du ein automatisches builsscrip tverwendest.manuell, baust einfach die nicht benötigten targets gar nicht erst
Devices innerhalb eines Targets wegzulassen dürfte keinen allzu wesentlichen Beitrag leisten das schneller zu bauen.
Sehe ich auch so; IIRC wird bestenfalls ein separater Kernel gebaut, ggf. aber nur das Image neu zusammengestellt.
Nächste Frage: wann ist »build prozess zu beschleunigen« so relevant, daß man ggf. Geräte im Netz von Updates ausschließt?
Build from Scratch dauert hier, je nach Buildserver, zw. 2 und 4 Stunden. Während FW-Entwicklung bauen wir nur x86-64 & ar71xx-generic (deutlich schneller) und testen die Funktion an VMs und ar71xx-generic-APs. Danach wird stumpf alles gebaut und gut.
Ok, schneller wirds also nicht.
Aber mein Patch spart dann einfach nur Speicherplatz. Und der Upload der Firmware auf unseren Webserver am Ende wird schneller.
Die Upgrades von Geräten, die keiner bei uns hat sind ja wirklich überflüssig.
Gibt es noch Kandidaten, die ich weglassen kann? Ich würde gern auf Geräte verzichten, die sehr alt sind und die Wahrscheinlichkeit, dass jemand noch mit so einem ankommt sehr gering ist. Oder sind in anderen Targets auch noch deprecated Geräte?
Hmm.
ffgt@colosses:~/jenkins_data/build$ du -sh /firmware/{experimental,master,packages,rawhide,stable,testing,tng}
65G /firmware/experimental
77G /firmware/master
22G /firmware/packages
259G /firmware/rawhide
17G /firmware/stable
9,8G /firmware/testing
70G /firmware/tng
Wir haben rawhide (jeder Build) ⇒ experimental (manuelle Kopieraktion) ⇒ testing (manuell) ⇒ stable (manuell), parallel zu rawhide gibt es noch master und tng (jeweils jeder Build), master wäre ein Build aus Gluon-Master, tng ist der early-adopter-channel für anstehende Gluon-Versionswechsel.
So exorbitant groß sind die Verzeichnisse jetzt nicht, und die Versionen reichen ca. 5 Jahre zurück … aber leider krepiert der Gluon-FW-Selector an der schieren Anzahl der Dateien.
Derzeit bauen wir in Helsinki und rsyncen nach Düsseldorf — über GBit ist das nichts, was groß auffällig wäre (ffgt@tomjon:~/build$ time ./mk-ffgt-2021_1.sh && ./rsync-firmware.sh).
Ja, gefühlt 90% der Images bauen auch wir für /dev/null, weil sie (wahrscheinlich) niemals jemand nutzen wird — insofern wäre eine Feedback-Loop aus den respondd-Daten zum Buildscript wünschenswert. Der »Migrationsanteil« aus anderen Communites ist ebenso eher marginal — insofern, falls das jemand bauen möchte – aus respondd-Daten die TARGETS-Liste für den nächsten FW-Bau erzeugen – feel free and ad me to your announce-list …
Das wäre super.
Oder eine Liste aller Router, die in der Freifunk-Api irgendwo auftauchen
Du möchtest jetzt aber nicht über die Abdeckung/Unvollständigkeit der Freifunk.net-Api diskutieren, oder?
In Bezug auf Build-Dauer und benötigtem Speicherplatz ist der ausschlaggebende Faktor für welche Prozessorarchitekturen (nicht zu verwechseln mit Device Targets wie z.B. ath79-generic) gebaut wird. Denn jede neue Prozessorarchitektur legt eine komplett neue Toolchain an, mit eigenem gcc und allem was so dazu gehört. Auf den kleineren Hetzner vServern braucht es etwa eine halbe Stunde bis Stunde um eine Toolchain für eine Prozessorarchitektur zu bauen.
Ich hab das bei uns mal in den Build-Metadaten erfasst: site/build.yml at master · fflev/site · GitHub
Wie man da sehen kann lassen sich ar71xx-generic, ar71xx-nand, ar71xx-tiny, ath79-tiny, lantiq-xrx200 und lantiq-xway alle mit der mips_24kc-Toolchain bauen.
Ich hatte das damals in den güldenen Freifunkjahren, als noch mit Jenkins gebaut wurde, dazu verwendet gleichartige Prozessorarchitekturen nach Möglichkeit auf der gleichen VM zu bauen um den Reuse von Toolchains zu optimieren und nicht ständig Toolchains für einen Target-Build neu bauen zu müssen.
Unterm Strich, sobald die Toolchain einmal da ist, dauert das Bauen der entsprechenden Device Varianten (-generic, -tiny) nur ein paar Minuten mehr, ein weiteres Target (ar71xx, ath79) vielleicht 15 Minuten.
sollten wir das nicht mal an die Gluon entwichḱler melden? dann könnte man auf dem buildserver vielleicht 5 toolchains einsparen