Freetz - Geschwindigkeit oder Speicherplatz

[olistudent]

Momentan haben wir in Freetz 2 Toolchains, die für die unterschiedlichen Versionen der uClibc genutzt werden. uClibc-0.9.29 wird von den Laborfirmwares sowie 3270, 7240 und 7270 genutzt. Die restlichen Firmwares verwenden uClibc-0.9.28. Inzwischen gibt es auch eine uClibc-0.9.30. Hier ist also nicht auszuschließen, dass AVM mal auch damit experimentieren wird.

Für Freetz stellt sich hier die Frage:
Was passiert wenn man zwischen Firmwares mit unterschiedlichen Versionen wechselt?

Es gibt 2 Möglichkeiten, die wir intern schon diskutiert haben.
1. Entweder werden, so wie es im Moment ist, alle Dateien unter source/ gelöscht (also quasi ein "make dirclean")
2. Oder wir erzeugen 2 Unterverzeichnisse unter source (uClibc-0.9.28 und uClibc-0.9.29) und halten die Dateien darin "doppelt" vor. Darunter fielen z.B. die Target-Toolchain (falls selbst gebaut) und die Packages. Nicht dazu zählt der Kernel, da der nicht von der verwendeten uClibc abhängt.

Während Variante 1 bei einem Wechsel also alles neu bauen muss spart Variante 2 hier viel Zeit. Benötigt dafür aber mehr Speicherplatz.

MfG Oliver

 

[RalfFriedl]

Ich bin für unterschiedliche Verzeichnisse.
Bei unterschiedlichen Verzeichnissen kann man beim Wechsel der Version und Platzmangel immer noch von Hand ein "make dirclean" ausführen und hat damit vom Ergebnis das Gleiche wie bei der anderen Variante. Damit ist man also flexibler.
Im anderen Fall ließen sich nicht einfach mehrere Versionen der Toolchain vorhalten.

Als Bonus könnte man noch eine Option einbauen, die beim Erkennen des Wechsels automatisch "make dirclean" ausführt, wenn dafür Bedarf besteht.

 

[sf3978]

Ich bin für Variante 1, weil ich mehr Zeit und weniger Speicherplatz habe . Ich baue immer alles neu. Mit einem schnellen Rechner ist das kein Problem.

 

[matze1985]

ich bin eher für die 2 Variante, da die die erste ja eigentlich beinhaltet. (Wenn man nen dirclean macht)
Wenn man zu wenig Speicher hat, dann muss man halt regel mäßig mal nen dirclean ausführen.

Der normal User wird eh nicht oft zwischen den uClibc's hin und herspringen. Da bleibt es dann bei einer Version.
Dazu sollte man von Zeit zu Zeit auch mal neu auschecken und nciht nur svn up machen, dass bewahrt auch vor Fehlern.


@sf3978
Wenn man sowieso immer neu anfängt, dann ist es eigentlich egal.

 

[sf3978]

Wenn man sowieso immer neu anfängt, dann ist es eigentlich egal.

OK, dann harren wir mal der Dinge, die da kommen mögen.

 

[Silent-Tears]

Ich plädiere eher zur Variante mit dem mehr an Speicherplatz, denn Zeit ist Geld, und Speicherplatz kostet kaum nohc was. Und da man als Dev häufiger hin und herspringt, ist Zeit sowieso noch einmal wichtiger.

 

[meilon]

Ein, Zwei Verzeichnisse mehr schaden nicht, und wenn man gerade wenig Platz hat, macht man halt nen make dirclean oder sichert sich die config und löscht alles und wenn man es wieder braucht, checkt man es aus neu und packt die config wieder hinein (so handle ich das auf meinem Notebook)

 

[McNetic]

Ich plädiere dafür, Variante 2 zu implementieren, und zusätzlich eine Menuconfig-Option einzubauen, die, wenn gesetzt, dafür sorgt, daß vor dem Neubauen der neuen Toolchain usw. die alte komplett gelöscht wird. Wer also wenig Speicherplatz hat, macht das einfach an und hat dann wieder Variante 1.

 

[Darkyputz]

version 2 auch hier...das leben iss so kurz ,-)

 

[wengi]

Hi,

Variante 2.
Ich compiliere auf einem älteren Notebook.
Da lösche ich lieber per Hand und spare mir dafür viel Zeit.

wengi

 

[ao]

Variante 2 - aus den guten Gründen, die RalfFriedl oben schon geschrieben hat

 

[JanGerrit]

Hallo Miteinander,

ich bin auch der Meinung, dass die Version 2 vorzuziehen ist. Der Vorschlag von McNetic wäre ein guter Kompromiss.

Viele Grüße, Jan Gerrit

 

[Miyamoto]

Ich plädiere dafür, Variante 2 zu implementieren, und zusätzlich eine Menuconfig-Option einzubauen, die, wenn gesetzt, dafür sorgt, daß vor dem Neubauen der neuen Toolchain usw. die alte komplett gelöscht wird. Wer also wenig Speicherplatz hat, macht das einfach an und hat dann wieder Variante 1.

Das ist der sinnigste Vorschlag, finde ich - da können alle zufrieden sein. Mein source umfaßt schlappe 1,1 GB, das kann schon kritisch sein für Leute mit älteren Computern.

Ist das aufwendig?

 

[Silent-Tears]

Beides einzubauen ist natuürlich mehr Aufwand als nur eines daon. Logischerweise, oder?

 

[rodeoflip2009]

Punkt zwei ganz klar, die Vorteile wurden ja schon genannt.


mfg

 

[frodo.]

Ich bin für ein "make dirclean" in kombination mit verschiedenen Verzeichnissen pro Hardware.

Ich verwende für meine Zwecke schon heute für jede Hardwareversion ein eigenes Verzeichnis und führe nach jedem svn update ein make dirclean aus.

Ein Wechsel von verschiedener Hardwareversionen mit den selben bereits für eine andere Version verwendete Sourcen führte bei mir häufig zu nicht nachvollziehbaren Fehlern weshalb der Weg bisher nicht funktioniert.

Meine Favorisierte Lösung wäre für Hardware spezifische Besonderheiten pro Hardware ein eigenes Unterverzeichnis welches bei einem make dirclean entfernt wird. Für alle übergreifende ungepatchten Sourcen ein Common Source Verzeichnis was dann bei einem make dirclean auch nicht gelöscht werden muss.

Zusätzlich könnte man dann ein make dircleanall einbauen, welches alle Sourcen löscht.

Wenn hierdurch ein fehlerfreies Compilieren mit einem Freetz-Source Verzeichnis für alle Hardwareversionen funktioniert fände ich das auch OK.

Zur Zeit haben wir aber das Problem das man bereits kompilierte und anschliessend abgewählte Pakete nicht rückstandslos beseitigen kann, für eine Fritzbox mit weniger Flash-Speicher läst sich dadurch dann kein optimiertes Image mehr bauen...

 

[Silent-Tears]

Nette Gedanken, aber ich denke, ein wenig Handarbeit ist schon noch drin. Für jede HW und jede uClibc ein eigenes Unterverzeichnis, dazu noch am besten extra für jedes Flashgrösse, falls variabel ist irgendwie oversized imho. Ich lass mich aber gern vom Gegenteil überzeugen.
Die Sache mit den Rückstandslosen Dingen: Ein "make dirclean" tut seinen Zweck

 

[ao]

Zur Zeit haben wir aber das Problem das man bereits kompilierte und anschliessend abgewählte Pakete nicht rückstandslos beseitigen kann, für eine Fritzbox mit weniger Flash-Speicher läst sich dadurch dann kein optimiertes Image mehr bauen...

Dafür gibt es m.E. "make config-clean-deps".

Oder dies hier? Was ist da eigentlich der Unterschied?

Die Sache mit den Rückstandslosen Dingen: Ein "make dirclean" tut seinen Zweck

 

[lxuser]

@ ao

"make dirclean" bringt Frodo bei seinem Problem nichts. Überflüssige Libs... bleiben trotzdem in der Config und werden nach dem Löschen ja wieder mit "make" neu erstellt. Er braucht schon "make config-clean-deps" um die überflüssigen Abhängigkeiten aus der COnfig zu löschen als Lösung seines Problems.


Zur eigentlichen Frage, da ich auf alle Boxen ein und das selbe Image aus dem stable Traunk mit USB-Root schmeisse und dass System für den USB-Root aus dem Trunk nehme und fast jedesmal mit "svn up" neu ausschecke und bei neuen Revisionen eh ein "make dirclean" durchführe, ist es für mich eigentlich völlig egal. Solange dauert ein "make" ja nicht mehr seitdem ich Linux wieder nativ laufen lasse und nicht mehr in einer VM. Aber auch da hatte ich dann eher ein Platz-Problem.

Viele Grüss
Mario