LZMA-Unterstützung für Kernel 2.6

[rhabarber1848]

Kernel 2.6.25.6 zeigt folgende Warnung beim Kompilieren:

Code: Alles auswählen

  CC      fs/squashfs/inode.o
fs/squashfs/inode.c: In function `init_inodecache':
fs/squashfs/inode.c:2141: warning: passing arg 5 of `kmem_cache_create' from incompatible pointer type
  CC      fs/squashfs/LzmaDecode.o
  LD      fs/squashfs/squashfs.o
  LD      fs/squashfs/built-in.o

Ist mit diesem Patch behoben, keine Warnung mehr beim Kompilieren
und das Image bootet korrekt mit LZMA-Support:

Code: Alles auswählen

--- inode.c.org	2008-06-16 09:19:13.000000000 +0200
+++ inode.c	2008-06-16 10:11:28.000000000 +0200
@@ -43,6 +43,7 @@
 #include <linux/zlib.h>
 #include <linux/blkdev.h>
 #include <linux/vmalloc.h>
+#include <linux/version.h>
 #include <asm/uaccess.h>
 #include <asm/semaphore.h>
 
@@ -2124,9 +2125,13 @@
 	kmem_cache_free(squashfs_inode_cachep, SQUASHFS_I(inode));
 }
 
-
+#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,23)
 static void init_once(void * foo, struct kmem_cache * cachep, unsigned long flags)
 {
+#else
+static void init_once(struct kmem_cache * cachep, void * foo)
+{
+#endif
 	struct squashfs_inode_info *ei = foo;
 
 		inode_init_once(&ei->vfs_inode);

CC fs/squashfs/inode.o
CC fs/squashfs/LzmaDecode.o
LD fs/squashfs/squashfs.o
LD fs/squashfs/built-in.o

[seife]

Na gut. Haut mir den LZMA-Patch ins tuxbox-upload, und ich schau es mir am Wochenende an und checks ein.
Aber macht euch auf kontinuierliches Fixen gefasst, bald gibts ja 2.6.26 ;-)

[rhabarber1848]

Haut mir den LZMA-Patch ins tuxbox-upload

Bitte sehr: kernel26_lzma7.diff

Für Kernel 2.6-Support wäre noch der Busybox-modprobe-Patch wichtig:
http://forum.tuxbox-cvs.sourceforge.net ... 84#p357184

[mb405]

klasse
ich bastel gleich mal ein image, und dann guggmer mal obs geht.

[mohousch]

Na gut. Haut mir den LZMA-Patch ins tuxbox-upload, und ich schau es mir am Wochenende an und checks ein.
Aber macht euch auf kontinuierliches Fixen gefasst, bald gibts ja 2.6.26 ;-)

d.h ist denn besser den LZMA Patch für die Squashfs3.3 zu integrieren

[rhabarber1848]

d.h ist denn besser den LZMA Patch für die Squashfs3.3 zu integrieren

Viel Spaß mit U-Boot

[mb405]

nutzt das was ?

this patch adds the lzma support with the following constraints:

- it doesn't install the LZMA SDK files. I provide the import_lzma.sh
script to import the needs file from a lzma sdk release
- the imported lzma sdk files are _not touched_
- the lzma support is enabled defining the CONFIG_LZMA define
- I haven't tested this patch
- Use this patch at your own risk

The patch creates:

- the lib_lzma directory with the import_lzmasdk.sh script and a simple
front-end to LzmaDecode() fuction
- the include/lzma directory with some include files to use in the
U-Boot code

modifies:

- common/do_bootm.c file
- common/image.c file
- include/image.h file

Please read the lib_lzma/README.txt file.

http://www.mail-archive.com/u-boot-user ... ages.patch

[rhabarber1848]

nutzt das was ?

this patch adds the lzma support

http://www.mail-archive.com/u-boot-user ... ages.patch

Ich habe den Patch vor einigen Tagen auch gesehen. Soweit ich mich recht erinnere,
beinhaltet er nur LZMA-Support. Es wird aber ein kombinierter Squashfs+LZMA-Support
benötigt, um den Kernel booten zu können.
U-Boot kann von Haus aus kein Squashfs, dieser Support steckt in
boot/u-boot-tuxbox/fs/squashfs, welches vom Tuxbox-Projekt kommt.
Dieser Squashfs-Support ist (noch) nicht kompatibel mit neueren Squashfs-Versionen,
besagter Patch ändert AFAIK nichts daran.

[seife]

Ich habe es jetzt probiert, und LZMA verdoppelt fast die Bootzeit (48 Sekunden bis zum Bild ohne LZMA, 1:30 Minuten mit LZMA).

Ist es das wirklich wert?
Will vielleicht jemand dafür ne configure-Option machen?

Edit: Als Ausgleich für den entgangenen Platz könnte man ja mal wieder uclibc aus der Versenkung holen.

[rhabarber1848]

Will vielleicht jemand dafür ne configure-Option machen?

Gute Idee, bin bereits dabei. Allerdings würde ich das gerne als globale Option
--enable-lzma definieren, die auch für Kernel 2.4 Gültigkeit hat. Da LZMA hier per
Default aktiviert ist, würde ich den LZMA-Support für Kernel 2.6 ebenfalls per
Default aktivieren, was eine Änderung des aktuellen Verhaltens darstellt.
Das Abschalten wäre dann für beide Kernel-Versionen problemlos mit --disable-lzma möglich.

Einwände?

Ich glaube, dass wäre einfacher zu realisieren als uclibc-Support

[seife]

Das wäre super, dann bootet meine 2.4er-Box vermutlich auch wieder schnell ;-)

[rhabarber1848]

Das wäre super, dann bootet meine 2.4er-Box vermutlich auch wieder schnell ;-)

Erste Testergebnisse, alles mit Kernel 2.4, Bootzeitraum vom Deep Standby zum ersten TV-Bild:
- mit LZMA: 51s (nach nochmaligem Test, nun mit Ucodes, 56s), root-neutrino.squashfs 4276224 Byte
- ohne LZMA: 45s, root-neutrino.squashfs 5152768 Byte

Hier der Patch (nur für Kernel 2.4 wirksam) zum Testen: configure_lzma.patch

Bei unveränderten configure-Optionen wird LZMA aktiviert, bei --enable-lzma auch,
um LZMA abzuschalten, muss --disable-lzma angegeben werden.

Wenn der Patch funktioniert, würde ich mich freuen, wenn er ins CVS wandert,
dann kann ich den Kernel 2.6-LZMA-Patch leichter anpassen.

[dbt]

Danke auch. Das --enable-LZMA würde ich allerdings einfach weglassen, da es nur irritiert. --disable-LZMA würde voll ausreichen. Das war vorher ja auch default on. Ich würde nur in der Statusausgabe eine entsprechende Ausgabe Summary machen, etwa so:

Code: Alles auswählen

...
IDE support:                    yes
Ext2/3 support for IDE:         yes
XFS support for IDE:            yes
NFS server:                     yes
Samba server:                   yes
dosfstools:                     yes
Neutrino UPnP-support:          yes
FLAC support:                   yes
LZMA support:                   yes
...

Das Ganze noch entsprechend im Wiki dokumentiert und gut ist das...

[rhabarber1848]

Ich würde nur in der Statusausgabe eine entsprechende Ausgabe Summary machen

Ist schon im Patch enthalten:

root partition size: 0x660000
LZMA support: yes
default locale: deutsch

Da sich LZMA auf die Partitionsgrößen auswirkt, habe ich die LZMA-Info bei der root partition size angesiedelt.

[tcf4004]

Hab mal etwas mit den Patches und Kernel 2.4 getestet und festgestellt dass es mit --disable-lzma
auch funktioniert, rootfs ist dann ca. 4.6mb gross (ohne die Patches wird bei mir ein squashfs-lzma
rootfs mit einer Grösse von ca. 3.8mb erstellt).
Aber: auch mit --enable-lzma bzw. configure ohne option aufgerufen wird immer
ohne lzma gebaut, d.h. das rootfs ist immer ca. 4.6mb gross egal mit welcher
option configured wurde. In der Übersicht, die nach dem configure erscheint,
wird jedoch jeweils korrekt "LZMA support: yes/no" angezeigt.

Was ich auch noch festgestellt habe ist, dass beim jffs2 (!) bauen nun immer "bad magic bytes"
(nur beim 2x image, 1x ist ok) am Ende auftaucht. Nun ist das Thema "bad magic bytes" ja sehr komplex
Aber in diesem Fall konnte ich auch durch Reinkopieren/Löschen verschiedener (Dummy-)Dateien
nichts bewirken, beim jffs2-2x-img kommt offenbar immer bad magic bytes am Ende, squashfs hingegen läuft durch...
Ich habe das in 2 identischen VMs getestet, einmal mit Patches und einmal ohne.
In der VM ohne die Patches läuft das jffs2-Kompilieren einwandfrei durch, in der anderen -> bad magic bytes

[rhabarber1848]

Aber: auch mit --enable-lzma bzw. configure ohne option aufgerufen wird immer
ohne lzma gebaut

Hast Du einen neuen CVS-checkout dafür gemacht ein make clean* laufen lassen?

Bei mir ist root-neutrino.squashfs ohne LZMA 5152768 Byte gross, mit LZMA 4276224.

[tcf4004]

Zuletzt ausgecheckt habe ich Ende Juni, müsste so um den 30.06. gewesen sein, muss ich nachher mal nachschauen. Ist denn ein brandneues cvs nötig?

Die Patches (7 Dateien werden ja insgesamt angesprochen) konnte ich ohne Probleme auf diesen Stand applizieren, wurde also nix rejected oder so.

Vor dem Patchen (wie auch vor jedem Bauen) habe ich ein make flash-clean gemacht.
Wusste zuerst nicht ob das ausreicht, aber dann habe ich gesehen dass newmake die entsprechenden Teile wie mksquashfs & Co. neu baut.
Als es dann auch mit --disable-lzma funktionierte, dachte ich mir ok, dann muss das make flash-clean ja eigentlich ausgereicht haben...?
Notfalls könnte ich nochmal einen Test mit make distclean (das ist glaube ich das drastischte Reinigungstarget, oder?) und anschliessendem compile nachlegen, weiss aber noch nicht wann ich dazu komme.

Geht es denn bei Dir mit Kernel 2.4 und --enable-lzma bzw. ganz ohne configure option?
Hast Du evtl. auch bad magics bei jffs2?

[rhabarber1848]

Geht es denn bei Dir mit Kernel 2.4 und --enable-lzma bzw. ganz ohne configure option?

2 x Ja.

Allerdings muss ich gestehen, dass ich noch nie make clean*-Targets aufgerufen habe.
Ich habe hier ein Kopie des CVS, welches zum Kompilieren in ein neues Verzeichnis
kopiert wird. Vielleicht liegt das Problem darin, dass make flash-clean den bisherigen
LZMA-Parameter nicht zurücksetzt.

[seife]

$HOSTPREFIX/bin/mksquashfs wird nur wegen einer anderen ./configure-option nicht neu gebaut.

Die eleganteste Lösung wäre vermutlich, je nach configure-switch ein "mksquashfs-lzma" oder ein "mksquashfs" zu bauen und zu benutzen.

Wenn ich dazu komme, schaue ich mir das mal an.

[rhabarber1848]

Was ich auch noch festgestellt habe ist, dass beim jffs2 (!) bauen nun immer "bad magic bytes"
(nur beim 2x image, 1x ist ok) am Ende auftaucht.

Ich habe das gleiche Phänomen mit dem Squashfs-Image, allerdings
bootet das 2x-Image trotz der bad magic bytes-Warnung.

[tcf4004]

$HOSTPREFIX/bin/mksquashfs wird nur wegen einer anderen ./configure-option nicht neu gebaut.

Ah, das erklärt natürlich einiges... Hört sich gut an das mit den 2 mksquashfs Varianten

Aber eine Frage hätte ich noch: Warum wird der jffs2-Build auch beeinflusst/gepatcht?
Ich dachte lzma ist nur für squashfs implementiert?
Irgendwas läuft bei jffs2 nun anders ab und führt zu bad magic bytes, was beim gleichen Stand
ohne Patches nicht auftritt...?

Werde mal schauen ob ich am WE noch etwas testen kann

[rhabarber1848]

Warum wird der jffs2-Build auch beeinflusst/gepatcht?

Weil im Kernel der LZMA-Support fehlt.

Mit "make flash-clean" wird der Kernel allerdings nicht neu gebaut.

Wenn --disable-lzma genutzt wird, fehlt LZMA-Support im Kernel, der auch
mit ./configure --enable-lzma nicht mehr hinzugefügt wird.

[seife]

Am besten wäre es, wenn ein LZMA-gepatchter Kernel sowohl zlib als auch LZMA könnte. Dann wäre das alles kein Problem. Aber so, wie der LZMA-Patch sich in den Kernel reinprügelt, kann man das halt nicht ohne weiteres implementieren.

Es hat schon einen Grun, warum LZMA nicht die geringste Chance hat, in den Mainline-Kernel zu wandern, zumindest nicht in der aktuellen Ausführung.

[rhabarber1848]

Aber macht euch auf kontinuierliches Fixen gefasst, bald gibts ja 2.6.26 ;-)

Es wird noch besser:
http://bugzilla.kernel.org/show_bug.cgi?id=10845#c3

arch 'ppc' will be removed from 2.6.27

[seife]

arch 'ppc' will be removed from 2.6.27

Das macht nichts, dann nehmen wir halt "powerpc".