[fli4l] fli4l auf raspberry?

[Alexander Dahl]

Moin,

Matthias Taube schrieb Donnerstag, 21. Januar 2016, 15:24 (CET):
> Was ist eigentlich der Grund, für alternative Entwicklungslinien eine 
> Hardware ohne integrierten WLAN, DSL etc. zu wählen und nicht anstelle 
> dessen den OpenWRT-Ansatz - eigene Software auf vorhandener, günstiger 
> Router-Hardware - zu wählen?

Es gibt zweieinhalb Gründe:

a) wir wurden sehr viel öfter nach fli4l auf RPi gefragt, als nach
irgendeiner anderen Plattform. Das schließt sowohl Fragen hier in der
Newsgroup ein als auch im IRC und auf den Chemnitzer Linux-Tagen am
Stand.

b) die Hardware ist günstig, leicht zu beschaffen und darüber hinaus bei
vielen Entwicklern, Testern und Nutzern schon vorhanden.

c) wir haben genommen was wir hatten, anstatt intensiv zu recherchieren,
was denn nun die geilste Plattform wäre um anzufangen.

(Ähnliche Argumente gelten übrigens auch für das Banana Pi R1 Router
Board.)

Wie man die Woche bei der Frage nach UMTS ←→ WLAN Router gesehen hat,
sind aber auch mit den Plattformen praktische Anwendungen denkbar.

> Ist eine alternative Firmware für die vorhanden Router etwas völlig 
> anderes als den fli4l auf ARM zu portieren?

Was völlig anderes nicht, aber schon in gewisser Weise ein Vergleich von
Äpfeln mit Birnen. Dazu muss man sich verschiedene Dinge anschauen:

* das zugrunde liegende Buildsystem: fli4l verwendet hier buildroot. Das
ist nicht zu verwechseln mit dem Buildsystem von OpenWRT, welches die
Grundlage für alternative Firmware für Plasterouter ist. Da gibt es
gemeinsame Vorfahren, aber heutzutage sind das unterschiedliche
Buildsysteme mit unterschiedlichen Zielstellungen. Die von buildroot
unterstützten Targets sind da i.d.R. leistungsfähiger und eben so Sachen
wie Raspberry Pi, Beaglebone, RiotBoard usw. Darüberhinaus haben wir
festgestellt, dass buildroot das Bauen einer Firmware für verschiedene
Targets nur schlecht unterstützt und da stehen dann wieder unsere
derzeitige build- und Repository-Infrastruktur dagegen. Wir lassen uns
da aber gern eines besseren belehren. :-)

* Speicheranforderungen: fli4l nutzt zwar uClibc (bzw. in 4.0 jetzt
uClibc-ng) aber unterm Strich ist ein typischer fli4l zu groß für
Targets mit nur 4 oder 8 MB Flash. Es wäre sicherlich möglich da
abzuspecken oder auch kleine alternative Daemons zu nutzen wie bei
OpenWRT oder Freifunk, aber das ist sehr viel Arbeit und wir sehen
(derzeit?) Plasterouter nicht als Zielgruppe für fli4l. Auch das ist
nicht in Stein gemeißelt, aber ich würde auch nicht drauf warten, dass
man in absehbarer Zeit fli4l bspw. auf TP-Link Geräten einsetzen kann.
Dafür haben wir keine Entwickler*innen, die das übernehmen können oder
wollen.

Ist das bisschen erhellend für die Gründe warum wir welche Plattformen
unterstützen? Mehr fällt mir persönlich grad nicht ein. O:-)

Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: 02C8 A590 7FE5 CA5F 3601  D1D5 8FBA 7744 CC87 10D0