treewide: rename br-mesh to br-client #21

adschm · 2020-12-18T21:05:50+01:00

adschm commented

2020-12-18 21:05:50 +01:00

The name br-mesh is actually quite misleading, since the bridge
actually includes the "client" interfaces. In order to make this
obvious, and to prevent confusion with the properly named wXmesh
interfaces, rename them to br-client.

Note that br-mesh is also particularly disturbing for the layer 3
firmware without batman-adv.

The name br-mesh is actually quite misleading, since the bridge actually includes the "client" interfaces. In order to make this obvious, and to prevent confusion with the properly named wXmesh interfaces, rename them to br-client. Note that br-mesh is also particularly disturbing for the layer 3 firmware without batman-adv.

adschm added the

packages/fff

label 2020-12-18 21:05:50 +01:00

adschm added 1 commit 2020-12-18 21:05:51 +01:00

6c0aaef195 treewide: rename br-mesh to br-client

The name br-mesh is actually quite misleading, since the bridge
actually includes the "client" interfaces. In order to make this
obvious, and to prevent confusion with the properly named wXmesh
interfaces, rename them to br-client.

Note that br-mesh is also particularly disturbing for the layer 3
firmware without batman-adv.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

rohammer commented

2020-12-19 11:21:44 +01:00

Hi Adrian,
ich wuerde in einer br-client die Devices erwarten, an denen die "lokalen" Clients haengen. Das ist aber nur eine Teilmenge des mesh-Netzes, das momentan in br-mesh haengt. Also die Clientdevices und batman.
Bei der aktuellen l3-firmware sieht es noch anders aus. Kann sich aber aendern.
Oder hast du einen groesseren Plan, der die Umbenennung notwendig macht?
Ansonsten finde ich br-mesh passender.

Hi Adrian, ich wuerde in einer br-client die Devices erwarten, an denen die "lokalen" Clients haengen. Das ist aber nur eine Teilmenge des mesh-Netzes, das momentan in br-mesh haengt. Also die Clientdevices und batman. Bei der aktuellen l3-firmware sieht es noch anders aus. Kann sich aber aendern. Oder hast du einen groesseren Plan, der die Umbenennung notwendig macht? Ansonsten finde ich br-mesh passender.

adschm commented

2020-12-19 14:44:25 +01:00

Ich persönlich fand br-mesh schon immer irreführend. Sicher ist es auch ein bisschen die Schuld von Batman-adv selbst mit den mesh hardifs und softifs, die den Namen überladen. Aber speziell das wir eben sonst "mesh" nur für echte (hardif) mesh-Interfaces wie wXmesh und ethmesh verwenden, macht die Bezeichnung br-mesh sehr irreführend.

Im Nachhinein bin ich auch der Meinung, dass gerade dieser Name einer der Gründe war, warum ich sehr lange gebraucht habe, bis ich die Konfiguration in der Firmware wirklich verstanden hatte.

In Zeiten einer layer3-Firmware sind wir nun an einem Punkt, wo br-mesh nicht mehr nur (in meinen Augen) irreführend, sondern schlicht falsch ist. Zudem bin ich der Meinung, dass wir unabhängig davon, ob wir batman verwenden oder nicht, auch unsere Konfiguration vielleicht etwas unabhängiger davon gestalten sollten. Ich finde es wesentlich zielführender wenn es dann einfach "client" und "mesh" gibt, und dann kann man ggf. batman da konzeptionell aufpropfen.

Für mich erscheint es wesentlich sinnvoller und auch besser konzeptionell zu erklären, in der node-Firmware ein bat0 zu einer br-client hinzuzufügen, als in der layer3-Firmware ein br-mesh zu haben, was lediglich ein br-lan ist, während gleichzeitig vielleicht echte 802.11s mesh Interfaces konfiguriert sind. Das Label "client" ist immer zumindest teilweise richtig.

(Ich hatte zwischenzeitlich auch überlegt, einfach das br-lan von OpenWrt wieder als Name zu verwenden. Allerdings denke ich, dass "lan" für unseren Einsatzzweck nicht genau genug definiert ist; privates LAN vs. Freifunk LAN ...)

Ich persönlich fand br-mesh schon immer irreführend. Sicher ist es auch ein bisschen die Schuld von Batman-adv selbst mit den mesh hardifs und softifs, die den Namen überladen. Aber speziell das wir eben sonst "mesh" nur für echte (hardif) mesh-Interfaces wie wXmesh und ethmesh verwenden, macht die Bezeichnung br-mesh sehr irreführend. Im Nachhinein bin ich auch der Meinung, dass gerade dieser Name einer der Gründe war, warum ich sehr lange gebraucht habe, bis ich die Konfiguration in der Firmware wirklich verstanden hatte. In Zeiten einer layer3-Firmware sind wir nun an einem Punkt, wo br-mesh nicht mehr nur (in meinen Augen) irreführend, sondern schlicht falsch ist. Zudem bin ich der Meinung, dass wir unabhängig davon, ob wir batman verwenden oder nicht, auch unsere Konfiguration vielleicht etwas unabhängiger davon gestalten sollten. Ich finde es wesentlich zielführender wenn es dann einfach "client" und "mesh" gibt, und dann kann man ggf. batman da konzeptionell aufpropfen. Für mich erscheint es wesentlich sinnvoller und auch besser konzeptionell zu erklären, in der node-Firmware ein bat0 zu einer br-client hinzuzufügen, als in der layer3-Firmware ein br-mesh zu haben, was lediglich ein br-lan ist, während gleichzeitig vielleicht echte 802.11s mesh Interfaces konfiguriert sind. Das Label "client" ist immer zumindest teilweise richtig. (Ich hatte zwischenzeitlich auch überlegt, einfach das br-lan von OpenWrt wieder als Name zu verwenden. Allerdings denke ich, dass "lan" für unseren Einsatzzweck nicht genau genug definiert ist; privates LAN vs. Freifunk LAN ...)

fbl commented

2020-12-21 15:35:01 +01:00

Ich kann mich Adrian hier anschließen. Ich finde die Bezeichnung br-mesh unintuitiv, da das ja keine Bridge über Mesh-Interfaces (wXmesh, ethmesh, babel-interfaces etc.) ist, sondern des Netztes, welches über Mesh transportiert wird, also das Clientnetz.

Die Bezeichnung br-client finde ich deutlich intuitiver und wollte dafür eigentlich schonmal einen Patch machen.

Acked-by: Fabian Bläse <fabian@blaese.de>

Ich kann mich Adrian hier anschließen. Ich finde die Bezeichnung br-mesh unintuitiv, da das ja keine Bridge über Mesh-Interfaces (wXmesh, ethmesh, babel-interfaces etc.) ist, sondern des Netztes, welches über Mesh transportiert wird, also das Clientnetz. Die Bezeichnung br-client finde ich deutlich intuitiver und wollte dafür eigentlich schonmal einen Patch machen. Acked-by: Fabian Bläse \<fabian@blaese.de\>

jkimmel commented

2020-12-21 15:57:33 +01:00

Ich hab auch nochmal drueber nachgedacht und br-mesh ist definitiv nicht die richtige bezeichnung. br-client ist besser, aber fuer die node firmware waere wohl br-hood richtiger. Aber dann haben wir wieder den Salat mit der layer-3 firmware und nen anderen Namen fuer die selbe Aufgabe :)

Ich hab auch nochmal drueber nachgedacht und `br-mesh` ist definitiv nicht die richtige bezeichnung. `br-client` ist besser, aber fuer die node firmware waere wohl `br-hood` richtiger. Aber dann haben wir wieder den Salat mit der `layer-3` firmware und nen anderen Namen fuer die selbe Aufgabe :)

ChristianD commented

2020-12-21 17:06:17 +01:00

ich finde br-client auch deutlich besser. Da drin stecken die Clientinterfaces also ist es die Clientbridge => br-client

br-mesh wäre für mich etwas, wo z.b. w2mesh, w5mesh, eth0.3 drinnen stecken und dann per batctl if add br-mesh ins Batman gehangen wird, also worüber mesh transportiert wird.

Mir war diese Bezeichnung auch schon lange ein Dorn im Auge.

Acked-by: Christian Dresel <freifunk@dresel.systems>

ich finde br-client auch deutlich besser. Da drin stecken die Clientinterfaces also ist es die Clientbridge => br-client br-mesh wäre für mich etwas, wo z.b. w2mesh, w5mesh, eth0.3 drinnen stecken und dann per batctl if add br-mesh ins Batman gehangen wird, also worüber mesh transportiert wird. Mir war diese Bezeichnung auch schon lange ein Dorn im Auge. ``` Acked-by: Christian Dresel <freifunk@dresel.systems> ```

rohammer commented

2020-12-22 00:50:24 +01:00

Ihr habt auch mich ueberzeugt. br-client ist klarer.
Ich hab es mal schnell durchgegrept - keinen uebersehen!

Reviewed-by: Robert Langhammer <rlanghammer@web.de>

Ihr habt auch mich ueberzeugt. br-client ist klarer. Ich hab es mal schnell durchgegrept - keinen uebersehen! ``` Reviewed-by: Robert Langhammer <rlanghammer@web.de> ```

adschm commented

2020-12-22 13:45:21 +01:00

Danke für die rege Teilnahme. Wird gleich gemergt.

adschm closed this pull request

2020-12-22 13:45:21 +01:00