ds-mod ohne kompilieren?

[Psychodad]

Hi

Ich verfolge nun die Entwicklung hier schon seit längerem und es sieht wirklich toll aus was ihr da macht.

Nur, und ich denke ich bin da bei weitem nicht der Einzige, extra nur dafür unmengen von Software zu installieren finde ich einfach übertrieben. Anders gesagt übersteigt das einfach meine Fähiglkeiten, besonders auf dem Mac scheint es ja nicht wirklich zu funktionieren.

Daher möchte ich mal die Anregung einbringen, eine vereinfachte Installation für "normale" User anzubiete. Es ist ja wirklich Schade, dass nicht mehr Leute von eurer Arbeit profitieren können.

Meine (sicher völlig unqualifizierte) Idee wäre etwa folgende:

Man nehme die AVM-Firmware und ein ds-mod Image, dann macht man ein File welches nur die Unterschiede enthält (XOR-Verküpft oder sowas).

Diese Datei könnte man dann zum Download anbieten, da sie ja kein Bit einer original Firmware enthält. (oder?)

Der User braucht dann nur die AVM-Firmware von AVM downloaden und ein kleines Tool, dass aus den beiden Files wieder den ds-mod macht. (Wenns in Perl sein darf mach das sogar noch selber)

Was haltet ihr davon?

Psychodad

 

[danfeh]

Hi,

super Idee, wäre auch sehr angetan davon

Grüsse
Daniel

 

[bodega]

Die Idee ist gänzlich nicht schlecht. Leider hat AVM das nicht so gern, wenn gemoddete Firmwares verteilt werden.

 

[derheimi]

Hi, so neu ist diese Idee IMHO gar nicht: in den Paketen des dsmods sind in der Regel auch die Binaries drin, so dass man diese eigentlich nicht neu compilieren müsste, sondern "nur" auspacken und mit der AVM-Orig-FW zusammenfahren muss. [Man bräuchte also nur ein paar Tools (die man vorcompiliert für Windows/Linux zur Verfügung stellen könnte), mit denen man die Original-FW auspackt, die Änderungen einbaut und das ganze wieder zusammenbauen würde.]
Das ganze funktionierte dann nicht mehr, als AVM neuere FWs mit Kernel 2.6 und/oder neuer uclibc rausgebracht hat (Meldung "cannot resolve symbol" und Co). Die bisherige Struktur des dsmods war und ist dafür IMHO nicht ausgelegt (wobei das keine Kritik darstellen soll!!!). Benötigt würden da nämlich noch ein paar "Metainformationen" (Für-Kernel-XY, benötigt zusätzlich Paket-X usw.).

Der geplante Umstieg auf ipkg als Pakettool und das neue Build-System erschlagen bestimmt einige der Probleme, könnte ich mir vorstellen.

Aber so lange bin ich hier auch noch nicht dabei - vielleicht äußert sich mal jmd der davon Ahnung hat ;-)

EDIT:
@bodega:
Naja, es geht ja nicht darum, gemoddete Firmwares zu verteilen, es geht -so hab ich das zumindest verstanden- einfach nur darum, ein großes Repository (wie Debian, SuSE und Co) aufzubauen, wo die vorcompilerten Pakete liegen, so dass man nicht mehr selbst den GCC anwerfen muss.

 

[bodega]

mhh.. dann habe ich das wohl falsch verstanden.

Man nehme die AVM-Firmware und ein ds-mod Image, dann macht man ein File welches nur die Unterschiede enthält (XOR-Verküpft oder sowas).

Hatte sich so angehört, als würden dann jede Menge Images kursieren. ipkg ist wahrscheinlich besser.

BTW:
dachte immer, das die Binaries im ds-mod für cygwin-user sind. Kann das sein? Ich hab die zumindest immer gelöscht..

 

[olistudent]

Welche Binaries sollen für cygwin-user sein?

MfG Oliver

 

[Psychodad]

keine Images

Hi

Nein es sollen eben keine Images verteilt werden (AVM will das nicht).

Was ich meinte: Als User lade ich mir die Firmware von AVM runter, ganz offiziell halt. Und dann lasse ich ein Tool drüber welches alle Aenderungen des ds-mod in das vorhandene Image einbaut.
Also quasi ein Patch für die Original-Firmware. Der Patch selber enthält keinen Code von AVM, also auch kein Problem.

Der Patch müsste im Minimium IPKG enthalten, den Rest kann man dann ja komfortabel als Paket installieren.

by

Psychodad

Hatte sich so angehört, als würden dann jede Menge Images kursieren.

 

[Psychodad]

einfacher

Hi

Ich dachte eher noch einfacher: Das Tool braucht nur die Info welche Bytes in der Firmware wie geändert werden müssen.

Diese Information müsste _einmal_ von den ds-mod-Entwicklern erzeugt werden, durch Vergleich von AVM-Firmware und Ds-mod-Firmware.

Für die Programierer:

1.Entwickler macht (AVM-Image) XOR (DSMod-Image) = Patchfile

2.Patchfile wird veröffentlicht (enthält keinen AVM-Code)

3. User macht (AVM-Image) XOR (Patchfile) = DSMod-Image


Grüsse

Psychodad

Man bräuchte also nur ein paar Tools , mit denen man die Original-FW auspackt, die Änderungen einbaut und das ganze wieder zusammenbauen würde.].

 

[bodega]

@olistudent:

im meinte die Dateien unter usr\root\lib, bzw iptables unter \kernel\root\usr\sbin.

 

[olistudent]

Also, theoretisch ist es so, dass man ohne "make precompiled" auskommt, wenn die Libs und Module in den betreffenden Verzeichnissen vorhanden sind. Und die Packages die richtigen Binaries enthalten. Deshalb muss man für den ds-0.2.9 (in originaler Fassung) kein "make precompiled" machen. Ich müsste jetzt also alle Packages mit den Binaries für 2.6 aktualisieren, auf (m)einen Server legen und die URL in den *.mk Dateien anpassen. Dann bräuchte man kein "make precompiled".

MfG Oliver

 

[DPR]

Ich dachte eher noch einfacher: Das Tool braucht nur die Info welche Bytes in der Firmware wie geändert werden müssen.

Diese Information müsste _einmal_ von den ds-mod-Entwicklern erzeugt werden, durch Vergleich von AVM-Firmware und Ds-mod-Firmware.

Für die Programierer:

1.Entwickler macht (AVM-Image) XOR (DSMod-Image) = Patchfile

Ein binäres Diff halte ich nicht für sinnvoll. Denkbar wäre aber ein Paket mit den vorkompilierten (GPL) Binaries/Libraries anzubieten, das dann quasi nur noch den letzten make-Schritt macht und die Dateien in das Firmware-Image einspielt.

Sehe kein großes Problem darin das technisch zu realisieren. Andererseits sollte sich jeder, der seine Firmware modifiziert, bewusst sein, was er da tut ! Im schlimmsten Fall schrottet man damit seine Box oder öffnet irgendwelche Sicherheitslücken - in jedem Fall verliert man mit der Modifikation jeglichen Anspruch auf Garantie !

Ich denke mal, dass es Daniel und Oliver bisher einfach zu stressig war, vorkompilierte Pakete anzubieten und zu pflegen. Insbesondere, weil sich die dsmods von Oliver sowieso recht häufig ändern und ein überarbeitetes dsmod ansteht.

2.Patchfile wird veröffentlicht (enthält keinen AVM-Code)

Es geht nicht (nur) darum, ob ein Patch AVM-Code enthält. Jegliche Modifikation oder Manipulation an proprietärem Code ist nicht zulässig.

Also, theoretisch ist es so, dass man ohne "make precompiled" auskommt, wenn die Libs und Module in den betreffenden Verzeichnissen vorhanden sind. Und die Packages die richtigen Binaries enthalten. Deshalb muss man für den ds-0.2.9 (in originaler Fassung) kein "make precompiled" machen. Ich müsste jetzt also alle Packages mit den Binaries für 2.6 aktualisieren, auf (m)einen Server legen und die URL in den *.mk Dateien anpassen. Dann bräuchte man kein "make precompiled".

Prinzipiell kann man ja auf die komplette make-Umgebung verzichten ! Ein Archiv mit den vorkompilierten Binaries würde wie Oben beschrieben ja reichen. Und ein Script zum Ent-/Packen des Images ist ja schon vorhanden Eine kleine Anpassung und man braucht nicht mehr als ein TAR mit den Binaries / Verzeichnisstrukturen und das entsprechende Script.

@Oliver: eine Idee für diejenigen die lieber die make-Umgebung verwenden ... ich fände es nicht schlecht, wenn du schon den dicken Brocken "Crosscompiler" als vorkompiliertes Paket anbietest. Das kompilieren der GCC dürfte wohl einen größten Anteil des make-Vorgangs ausmachen. Und wenn man mal ein "clean" macht oder lieber die Strukturen neu aufsetzt, spart man damit sehr viel Zeit. Nur so als Anregung

 

[olistudent]

Sieht nach einem etwas großen Brocken aus:

-rw-r--r-- 1 oliver oliver 62366939 2007-03-13 15:46 toolchain.tar.bz2

MfG Oliver

 

[derheimi]

Man könnte auch versuchen, auf "externe Crosscompiler" zurückzugreifen (wenn denn die damit verbundenen "Abhängigkeiten" in Kauf genommen werden). Habe ich das richtig verstanden, dass diese Compiler immer sowohl von der Hostarchitektur (vermutlich hauptsächlich i386), der Zielarchitektur (hier: mipsel) und der libc (hier: für kernel glibc und userspace uclibc) abhängig sind? Unter http://debian.speedblue.org/ gibt es ja z.B. eine mipsel-glibc-Variante für Debian (und damit FriBoLi - wenn ich mich nicht irre). Vielleicht könnte man diese für das Bauen des Kernels verwenden?
Dann hätte man schonmal nur noch den Compiler für den Userspace.

Ok, mir fällt grade ein, dass man idealerweise die gleichen Compiler-Versionen wie AVM verwendet, richtig? Da müsste man mal vergleichen...

 

[danisahne]

Für die Programierer:

1.Entwickler macht (AVM-Image) XOR (DSMod-Image) = Patchfile

2.Patchfile wird veröffentlicht (enthält keinen AVM-Code)

3. User macht (AVM-Image) XOR (Patchfile) = DSMod-Image

Diesen Weg habe ich bewußt nicht eingeschlagen. Erstens soll der Vorgang des "Moddens" nachvollziehbar bleiben, zweitens will ich gänzlich weg von Patches. Patches müssen an jede Firmware angepasst werden und sie sind dem AVM Support nicht zuzumuten (trotz Hinweisen wenden sich immer wieder Leute an den Support, was mich persönlich ärgert). Das erhöht nur die Flut an Supportfällen. Am wichtigsten ist mir dabei aber die schon die Nachvollziehbarkeit, da du einem diff rein garnicht ansiehst, ob es "böse" Software enthält. Im ds-mod kann das jeder selbst nachvollziehen, wenn er will.

Außerdem will ich, dass sich jeder mit der Materie beschäftigt, bevor er sich irgendein Image flasht.

Mfg
danisahne

 

[knox]

zweitens will ich gänzlich weg von Patches.

oh, schade. ich will lieber die binärdateien los werden

mir gefallen die binäre anteile im ds-mod eigentlich überhaupt nicht: viel besser fände ich eine rein auf textdateien (makefiles, patches, usw) basierendes buildroot gerüst, so wie man es zb von gentoo oder openwrt her kennt. mit hilfe von profilen o.ä. könnte man dann einfach mit den unterschiedlichen box-versionen hantieren.

natürlich sind binärdateien für den einsteiger leichter zu handhaben, aber sie erzeugen für die entwickler einen erhöhten aufwand der wiederkehrenden bereitstellung.

Am wichtigsten ist mir dabei aber die schon die Nachvollziehbarkeit, da du einem diff rein garnicht ansiehst, ob es "böse" Software enthält.

selbiges trifft natürlich auch auf "vollständige" binärdateien zu. der weg über ein buildroot in kombination mit (md5-validierten) original sourcecode-downloads ist da wesentlich zuverlässiger und der anwender behält die vollständige kontrolle über das, was er auf seine box installiert.

Außerdem will ich, dass sich jeder mit der Materie beschäftigt, bevor er sich irgendein Image flasht.

dem ist ausdrücklich zuzustimmen. immerhin geht mit der installation eines mods die garantie für die fritzbox verloren. da sollte jeder schon genau wissen, was er tut - oder lieber die finger davon lassen!

ds-mod ohne kompilieren? lieber nicht!

 

[danisahne]

oh, schade. ich will lieber die binärdateien los werden

Ich sollte das vielleicht nochmal deutlicher sagen: Ich will von Patches der Firmware weg. Also keine Patches, die Originaldateien der Firmware oder die Firmware als ganzes ändern.

Patches von Open Source Software im Buildroot: unbedingt! Das Buildroot mit Download von Sourcecode, Patches und kompilieren bleibt erhalten, das ist ja genau das, was ich unter Nachvollziehbarkeit verstehe. Auch mit iPKG ändert sich da nichts: Zuerst werden die iPKG Pakete erstellt und beim Bau der Firmware in das Image installiert. Bei Boxen mit zusätzlichen rw Speicher können die Pakete dann sogar noch nachträglich installiert werden. Zusätzlich zum buildroot, in dem alles von Grund auf kompiliert wird, soll es eine Variante geben, in der die iPKG Pakete schon vorkompiliert sind. So kann es sich jeder raussuchen, worin er sein Vertrauen steckt.

Mir sind wirklich nur die Patches der Dateien in der Originalfirmware ein Dorn im Auge. Aus gleichem Grund wird es nie ein XOR diff zu einer kompletten Firmware geben, was in diesem Thread gefragt wurde.

Mfg
danisahne

 

[Psychodad]

schade

Patches müssen an jede Firmware angepasst werden und sie sind dem AVM Support nicht zuzumuten

Das mit dem Anpassen stimmt natürlich, liesse sich aber auch automatisieren.
Was den Support von AVM betrifft: Ist ja eigentlich nicht dein Problem, mehr als darauf Hinweisen kannst Du ja doch nicht.

...
Am wichtigsten ist mir dabei aber die schon die Nachvollziehbarkeit, da du einem diff rein garnicht ansiehst, ob es "böse" Software enthält. Im ds-mod kann das jeder selbst nachvollziehen, wenn er will.

Das stimmt schlicht nicht, 99% der Leute können das überhaupt nicht nachvollziehen weil sie halt keine Programierer sind. Und Du hast sicher auch nicht die 60MB der Toolchain im Sourcecode durchgelesen...
Verstehe das jetzt bitte nicht als Angriff, ich mag "open source", nur bin ich mir bewusst das das mit "open" meist nicht viel zu tun hat.

Aber wenn der Patch noch mit einem Hash gesichert wird dürfte das onehin kein wirkliches Problem sein. (Immerhin dürften Millionen von Linux-Usern ihr System als binary runtergeladen haben)

...
Außerdem will ich, dass sich jeder mit der Materie beschäftigt, bevor er sich irgendein Image flasht.

ja, nun, da kann ich Dir nur schwer wiedersprechen, ich verstehe diese Einstellung. Aber hab doch ein wenig Verständniss für die nicht Linux-Freaks. Ich z.B. weiss als Elektroniker sehr wohl was ein Image flashen bedeutet (wirklich ;-) ), aber die ganzen Tools auf meinen Rechner (Mac) zu installieren würde mich sicher Wochen kosten - Zeit die ich lieber für was anderes brauche.

Aber ich denke mit der Zeit wird sich schon etwas ergeben.

Gruss

Psychodad