OpenWRT 18.06

Fabian Bläse fabian at blaese.de
Mi Okt 17 14:48:12 CEST 2018


Hallo Adrian,

ich würde Tims Patchset nochmal überarbeiten und ggf. auch pflegen.
Das Set nachträglich nochmal auf deine Variante umzustellen wäre auch kein Riesenaufwand, sollte sich herausstellen, dass das doch die bessere Variante gewesen wäre.

Ich teste das (leicht überarbeitete) Patchset von Tim seit einiger Zeit auf meinen Routern. Funktioniert bisher einwandfrei.

Mir wäre es auch ganz lieb, wenn wir an diesem OpenWRT Patchset jetzt nicht Ewigkeiten hängen würden.
Ob und wie viel ich in nächster Zeit in Richtung V2 entwickle.. Wahrscheinlich eher wenig.
Ich würde aber dennoch gerne an der Entwicklung dran bleiben und eine Art Gatewayfirmware Upstream bringen.

@Tim: Planst du dein Patchset nochmal zu überarbeiten?

Gruß
Fabian


On 17.10.18 14:25, Adrian Schmutzler wrote:
> Hallo,
> 
> nachdem sich hier ja wenig tut, sollten wir uns mal klar werden, wie es weiter geht:
> 
> Falls Tim generell keine Lust mehr auf die FW-Entwicklung hat (und es nicht an Zeit etc. liegt), wäre vll. zu überlegen, ob es mehr Sinn macht, meine Variante zu verwenden, wenn ich die dann maßgeblich weiter pflegen soll.
> 
> Falls von Tim oder Fabian mindestens einer Lust hat, das Thema OpenWRT-Update weiter zu treiben und die Patches zu basteln/aktualisieren, möge er das bitte tun. (z.B. auch Fabian Tims Patches überarbeiten, und dann gehen sie mit einem ACK statt Review durch ...) Dann wäre es aber wünschenswert, wenn es "in Zukunft" auch diesbezüglich einen Mindestumfang an Wartung gibt, da ich nicht glaube, dass ich das bei Tims Variante ohne weiteres übernehmen kann/möchte.
> 
> So oder so würde ich das Thema nun gerne mal einer Lösung zuführen. In beiden Fällen bleiben die meisten anderen Dinge ja vom OpenWRT-Update erstmal unberührt.
> Ich möchte nur zwei Dinge vermeiden:
> 1. Wir blockieren weitere Entwicklung oder den Einstieg/die Teilnahme von anderen Personen durch das OpenWRT-Update, das nicht weiter geht
> 2. Wir entscheiden uns für eine Lösung, für die dann hinterher niemand zur "Wartung" bereit steht
> 
> Vielleicht kriegen wir das ja doch irgendwie hin; ich glaube, vom Warten wird sich jetzt nichts mehr ändern.
> 
> Beste Grüße
> 
> Adrian
> 
> 
> 
>> -----Original Message-----
>> From: mail at adrianschmutzler.de [mailto:mail at adrianschmutzler.de]
>> Sent: Sonntag, 30. September 2018 14:32
>> To: 'Fabian Bläse' <fabian at blaese.de>; franken-dev at freifunk.net
>> Subject: RE: OpenWRT 18.06
>>
>> Hallo Fabian und Tim,
>>
>> vielen Dank für deine entsprechenden Recherchen.
>>
>> Damit wir hier weiter kommen, müsste, wenn ich das richtig sehe, Tim die
>> Patches 2 und 7 anpassen und du dann beide reviewen (Nr. 7 müsste ich dann
>> auch reviewen können).
>>
>> Bei Nr. 5 wollte ich noch ein Version-Increment, daran soll's aber nicht
>> scheitern.
>>
>> Kriegen wir das hin?
>>
>> Grüße
>>
>> Adrian
>>
>>> -----Original Message-----
>>> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf
>>> Of Fabian Bläse
>>> Sent: Samstag, 29. September 2018 22:33
>>> To: franken-dev at freifunk.net
>>> Subject: Re: OpenWRT 18.06
>>>
>>> Noch eine kleine Ergänzung:
>>>
>>> Scheinbar gibt es vieles davon bisher nur im master. In openwrt-18.06 ist
>>> vor
>>> allem die -Os Option bisher nicht drin. Später würde sich diese auch durch
>>> unsere eigene Config überschreiben lassen.
>>>
>>> Gruß
>>> Fabian
>>>
>>> On 23.09.18 22:37, Fabian Bläse wrote:
>>>> Hallo zusammen,
>>>>
>>>> ich hab mir mal die Unterschiede zwischen dem generic und dem tiny
>>> Target angeschaut:
>>>> Bis auf ein paar Änderungen in der Kernel Config scheinen die sich nicht
>>>> zu
>>> unterscheiden.
>>>>
>>>> Am interessantesten:
>>>> - squashfs-blocksize ist 1024, falls LOW_MEMORY_FOOTPRINT nicht gesetzt
>>> ist (was soweit ich das richtig sehe der Fall ist), ansonsten 256. Das
>>> überschreiben wir aktuell aber sowieso manuell iirc.
>>>> - Kernel wird bei tiny mit Optimierung auf Größe gebaut, statt mit -O2
>>>> - Kernel wird ohne Debugsymbole gebaut
>>>> - SWAP wird nicht unterstützt
>>>> - Kein stack trace im kernel-oops
>>>> - Kein Coredump
>>>> - Kleinerer squashfs Fragment-Cache
>>>>
>>>> Siehe auch: openwrt git -> config -> Config-images.in und
>>>> Config-kernel.in
>>>>
>>>> Ansonsten hab ich keine Unterschiede gefunden.
>>>>
>>>> Insgesamt kann ich beide Seiten verstehen.
>>>> Den OpenWRT Weg zu gehen kostet uns langfristig wohl mehr Arbeit beim
>>> testen der Releases, da Targets auseinander driften können.
>>>> Alles nach tiny zu werfen könnte bei OpenWRT Änderungen ein wenig
>>> Arbeit bedeuten. Da der Patch, das zu erreichen, aber ziemlich klein ist,
>>> halte
>>> ich das für irrelevant.
>>>>
>>>> Von daher würde ich mal mit dem Patch anfangen, alles nach tiny zu
>>> packen.
>>>> Schlussendlich ist das ja auch keine Entscheidung für die Ewigkeit.
>>>>
>>>> Gruß
>>>> Fabian
>>>>

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20181017/3d36ac25/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev