Running with compressed kernelmodules

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#16 Post by Karl Godt »

Now I had the time to apply

Code: Select all

find . | cpio -o -H newc | gzip -9 > ../initrd-ko-modules.gz
from rcrsn51 inside
pwd
/root/my-applications/initrd-FOX-3-NEW
after I ran

Code: Select all

find -type f -name "*.gz" -exec gunzip {} \;
inside
pwd
/root/my-applications/initrd-FOX-3-NEW/lib
and the second time
I think that is not correct because double compression always increases a size of the target file.
is true :
original initrd.gz with .ko.gz inside : 1394 K
new initrd.gz with .ko inside : 1368 K

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#17 Post by technosaurus »

goingnuts did some experiments in pupngo and IIRC when he built the sfs file (or was it the initrd?) with gzipped modules, it actually got bigger - wondering if xz would fare similarly, I'll add it to the todo list for features in the zdrv cutter (defaulting to gz, but with option for others)

the lzma/xz maintainer (lasse collin) posted kernel and squashfs patches too
http://www.mail-archive.com/linux-embed ... ernel.org/
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#18 Post by amigo »

Double-compression should always make things bigger, since each file must have the decompressor code added to it. xz is considerably slower than gzip, though for single small items it shouldn't make too much difference. I am surprised at the amount of compression you guys are reporting regardless of which tool is being used -most kernel code(modules) is quite dense and doesn't compress much no matter what you use. Another consideration is that when you use compressed items it takes RAM space to decompress them. This can become problematic when the items are large -especially with lzma/xz as it takes much more RAM than other compression methods.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#19 Post by Karl Godt »

Another consideration is that when you use compressed items it takes RAM space to decompress them. This can become problematic when the items are large -especially with lzma/xz as it takes much more RAM than other compression methods.
The first impressions are that way but it depends on the level . What I would need are approx. numbers like twice as much or 1.2 as much and this kind .


I am running now my first own modified initrd.gz at a frugall installation which worked both with and without loading the savefile . Adding a lot of unarchival utils and module-tools and fsck got me a 748 kb bb-1.17.1 and another with additional tools for the rdsh like less,more,ed,blkid,uptime,which,diff,... made the bb growing to 832kb. Including the original e2fsck which is 173kb but with uncompressed kernelmodules the initrd.gz became 1383kb instead of the original 1392kb. The first two boots paniced because I had forgotten to adjust the entries at /lib/modules/2.6.30.5/modules.dep from *.ko.gz to *.ko inside the initrd folder . If lzma *.ko would reduce the size of the modules which are uncompressed 1003kb and gzip 407kb down to 300-350kb I would be happy because this would enable some console and init features at bb .

And puppy for older hardware ? There are actually no kernels for real old hardware anymore . The original BB of the initrd.gz is version 1.4.2 with a size of 253kb statically . The first 1.17.1 that resembled the 1.4.2 I made several ours ago had been 728kb statically.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#20 Post by Karl Godt »

One disadvantage of the BB find applet is the missing "-noleaf" option that is used to
"\-noleaf"
Do not optimize by assuming that directories contain 2 fewer
subdirectories than their hard link count. This option is needed when
searching filesystems that do not follow the Unix directory-link
convention, such as CD-ROM or MS-DOS filesystems or AFS volume mount
points. Each directory on a normal Unix filesystem has at least 2
hard links: its name and its `.' entry. Additionally, its
subdirectories (if any) each have a `..' entry linked to that
directory. When
find
is examining a directory, after it has statted 2 fewer subdirectories
than the directory's link count, it knows that the rest of the entries
in the directory are non-directories (`leaf' files in the directory
tree). If only the files' names need to be examined, there is no need
to stat them; this gives a significant increase in search speed.
two times at the init[.sh] while version upgrade :

Code: Select all

if [ $NEWPVERSION -gt $OLDPVERSION ];then
  echo -e "\\033[1;35m"  >/dev/console #35=purple.
  echo "Version update, restoring 'official' files, please wait..." >/dev/console
  echo -en "\\033[0;39m" >/dev/console

#v2.12 this while-loop has become ultra-slow... seems upx compressed execs
  #responsible, recently upx-ed all the execs, now restore busybox, grep, cp.
  DOTCNT=0
  find ./ -noleaf -type f | sed -e 's/^\.//g' |
and :

Code: Select all

#need to cleanup whiteout files if a new .sfs layer has been added...
 if [ "$NEWUNIONRECORD" != "" -o "$PPURGE" = "yes" ];then
  #find all .wh.__dir_opaque files at the OLDFILESMNTPT layer... v424 bugfixes...
  cd $OLDFILESMNTPT
  find ./ -noleaf -type f -name ".wh.*" | sed -e 's/^\.//g' |
I don"t know if this does matter or if there are option combinations that would achieve the same. I am also not able to compile findutils ( 4.1.20 , 4.4.0 and 4.5 9 ) statically , even after googling around one or two hours. :x
The configure option description is very common and not very specific :
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-leaf-optimisation
Enable an optimisation which saves lstat calls to
identify subdirectories on filesystems having
traditional Unix semantics
--enable-d_type-optimization
Make use of the file type data returned in struct
dirent.d_type by readdir()
--enable-d_type-optimisation
Synonym for --enable-d_type-optimization

PANZERKOPF
Posts: 282
Joined: Wed 16 Dec 2009, 21:38
Location: Earth

#21 Post by PANZERKOPF »

Karl Godt wrote:. I am also not able to compile findutils ( 4.1.20 , 4.4.0 and 4.5 9 ) statically , even after googling around one or two hours. :x
Did you try to set LDFLAGS variable?
LDFLAGS="-static"
SUUM CUIQUE.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#22 Post by Karl Godt »

LDFLAGS="-static"
yes :
> ./configure --prefix=/usr
> mmake LDFAGS=-static
> make --prefix=$LFS/usr install does the trick
from
http://www.linuxfromscratch.org/piperma ... 06299.html
but :
static find became 808kb and `strip find` 519kb against the 55/60kb inside the initrd ( same version 4.1.20 ) from http://ftp.gnu.org/gnu/findutils/ the largest difference between a static and a shared binary that I have seen so far ( usually 2 to 4 times larger ) . How to disable features ? The features.h at the common /usr/include seems to be ok and --disable-group --disable-ctime --disable-empty --disable-10-or-more-find-options didn't get me further : no halt on an error and no reduction of size :cry:

PANZERKOPF
Posts: 282
Joined: Wed 16 Dec 2009, 21:38
Location: Earth

#23 Post by PANZERKOPF »

Karl Godt wrote:
LDFLAGS="-static"
no halt on an error and no reduction of size :cry:
I never make It but maybe a find utility can be compiled statically with
uclibc or dietlibc? These libraries are smaller (and possibly faster) than libc.
Also CFLAGS="-Os" reduces a size.
SUUM CUIQUE.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#24 Post by technosaurus »

glibc static compiles are always pretty large (compare the glibc implementation of ldconfig and sln at over 500k to the uclibc versions that are under 50k)

Rob Landley has a nice uClibc{++} toolchain at http://www.landley.net/aboriginal/downloads/binaries/

I don't have my notes handy at the moment but IIRC you'll need
Do not use a devx.sfs in combination, but have it mounted to get binaries
CFLAGS=" -muclibc -static -I/usr/include/c -I/usr/include/c++ -Os ..." <<--may not be exact
you will may want to build ncurses for busybox build (its easier than finding all the files)

If you want to compile more than just basic apps I recommend getting additional patches from openwrt (I was even able to build geany and scintilla with those)

note1: btw the really large linux from scratch file there can be renamed to *.sfs and mounted in order to do an automated LFS bootstrap (which includes apps mentioned above)

note2: may put alpine linux on a spare partition to keep an updated uclibc system (another good source of uclibc{++} patches)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#25 Post by Karl Godt »

Code: Select all

./configure LDFLAGS=-static CFLAGS=-Os
find-4.1.20 : 681kb , strip 434kb
find-4.4.0 : 1085kb , strip 758kb

Best founds for "Complete list of compiler options" :
http://msdn.microsoft.com/en-us/library ... 71%29.aspx
http://en.gentoo-wiki.com/wiki/CFLAGS
/Os Favors small code
-Os
-Os optimizes for size. -Os enables all -O2 optimizations that do not usually increase code size and performs further optimizations designed to reduce code size.
-Os is very useful for large applications, like Firefox, as it will reduce load time, memory usage, cache misses, disk usage etc. Code compiled with -Os can be faster than -O2 or -O3 because of this. It's also recommended for older computers with a low amount of RAM, disk space or cache on the CPU. But beware that -Os is not as well tested as -O2 and might trigger compiler bugs.
downloaded uclibc-0.9.30.2-src and this has got a menuconfig that is also quite large ..... Locale doesn't automatically download : wget 404 ....

What would I need to pass to ./configure that make uses the uclibc ?

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#26 Post by Karl Godt »

ERRATA : -Os + strip didn't made find 434kb , it became 511kb ... so it seems that -Os doesn't do much that strip can't do ......

Anyhow : I've got now some uclibc files at
make install PREFIX=/opt/ULIBC/001
make install_runtime PREFIX=/opt/ULIBC/001
make install_headers PREFIX=/opt/ULIBC/001
make install_utils PREFIX=/opt/ULIBC/001
make install_hostutils PREFIX=/opt/ULIBC/001

/opt/ULIBC/001/usr/i386-linux-uclibc

and found out that there are already some few files at

/usr/dietlibc at my fullinstall + devx

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#27 Post by Karl Godt »

I recommend getting additional patches from openwrt
http://downloads.openwrt.org/sources/

They have complete source there and I had to use save link as on .tar.gz at my firefox to prevent it beeing rendered inside the browser ... something I had occassionally with .pets ( ibiblio I think )
may put alpine linux on a spare partition
http://alpinelinux.org/wiki/Main_Page

.iso : 193MiB and where are the large files at openwrt ?

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#28 Post by Karl Godt »

About man /opt/diet/man/man1/diet.1 :
diet(1) diet(1)
NAME
diet - mangle gcc command line arguments
SYNOPSIS
diet [-v] [-Os] [normal gcc command line]
DESCRIPTION
diet is a small wrapper around gcc. It will try to look at the command
line you specify and try to mangle it so that gcc will compile against
the diet libc header files and link against the diet libc itself.

diet tries to be smart for cross compiling. If the first argument is
not gcc but sparc-linux-gcc, diet will guess that you want to cross
compile for sparc and use bin-sparc/dietlibc.a instead of the
dietlibc.a for your default architecture.

The -v option will make diet print the modified gcc command line before
executing it.

When passed the -Os option before the gcc argument, diet will mangle
the gcc options to include the best known for-size optimization set-
tings for the platform.
FILES
~/.diet/compiler may contain compiler options as you would specify them
on the command line, i.e. separated by spaces. Those will then be used
instead of the built-in defaults for diet -Os.
AUTHOR
Felix von Leitner <felix-dietlibc@fefe.de>
April 2001 diet(1)
it seems that to use it I would have to find+replace "gcc" with "diet" at all makefiles insinde the source ?

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#29 Post by technosaurus »

dietlibc is difficult to build more complex applications with but there is a FAQ here:
http://www.fefe.de/dietlibc/FAQ.txt

"diet" is just a wrapper
before you start hacking away at the source, try this though:
CC="diet gcc -nostdinc" CFLAGS=" -D_BSD_SOURCE ... "

you may get warnings of missing include files (blah blah linux/*.h or similar) you _can_ copy them from /usr/include to /usr/diet/include got get it to at least _try_ to build

besides using the -Os flag, the best size saving C{XX}FLAGS are -ffunction-sections and -fdata-sections when combined with the LDFLAGS -Wl,--gc-sections (as of gcc-4.5.2 the -flto related flags essentially replaces these) (--as-needed is a good ldflag too)

a little bit more details in the pet packaging 100/101 section of my signature
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#30 Post by Karl Godt »

About dietlibc : No success to compile `find` with

Code: Select all

./configure LDFLAGS="-static -Wl,--gc-sections,--as-needed" CFLAGS="-ffunction-sections -fdata-sections -Os" CC="diet gcc -nostdinc" CFLAGS="-D _BSD_SOURCE"
find-4.1.20 :
getline.h:35: error: conflicting types for 'gnu_getline'
/usr/dietlibc/include/stdio.h:191: error: previous declaration of 'gnu_getline' was here
getline.h:38: error: conflicting types for 'getdelim'
/usr/dietlibc/include/stdio.h:192: error: previous declaration of 'getdelim' was here
getline.c:139: error: conflicting types for 'gnu_getline'
/usr/dietlibc/include/stdio.h:191: error: previous declaration of 'gnu_getline' was here
getline.c:145: error: conflicting types for 'getdelim'
/usr/dietlibc/include/stdio.h:192: error: previous declaration of 'getdelim' was here
after /* uncommenting */ these two it stopped at two other files .

find-4.4.0 :
./stdio.h:395: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'rpl_getline'
/usr/dietlibc/include/sys/time.h:10: error: expected specifier-qualifier-list before 'time_t'
/usr/dietlibc/include/signal.h:265: error: expected specifier-qualifier-list before 'pid_t'
/usr/dietlibc/include/sys/fsuid.h:9: error: expected ')' before 'uid'
/usr/dietlibc/include/unistd.h:36: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'lseek'
/usr/dietlibc/include/time.h:20: error: expected ')' before 'clock_id'
/usr/dietlibc/include/wchar.h:34: error: expected ')' before '*' token

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#31 Post by technosaurus »

yes you have come across another of the many programs that is riddled with "GNU=isms" It would probably need getline instead of gnu_getline (may need to change the constructs a bit) ... comment out getdelim in the find code so that it uses the diet version and define the types (pid_t and time_t) with their corresponding types such as:
#define pid_t int //maybe unsigned int?

As you can see, it takes some time and work to get things to work with dietlibc (including making use of libowfat sometimes)

see my efforts here:
http://code.google.com/p/diet-binaries/downloads/list
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#32 Post by amigo »

Karl, you need to get your CFLAGS all together like this:
CFLAGS="-ffunction-sections -fdata-sections -Os -D _BSD_SOURCE"
Otherwise only the last part is being set.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#33 Post by Karl Godt »

Finally I got me a find-4.1.20 of 92kb (/1.024 /1.024 = 87kb) :

Code: Select all

./configure LDFLAGS="-static -Wl,--gc-sections,--as-needed" CFLAGS="-ffunction-sections -fdata-sections -Os -D _BSD_SOURCE" CC="diet gcc -nostdinc"
- which behaves like before -
l10nflist.c:(.text._nl_make_l10nflist+0x1b0): undefined reference to `stpcpy'
l10nflist.c:(.text._nl_make_l10nflist+0x1cc): undefined reference to `stpcpy'
../intl/libintl.a(l10nflist.o):l10nflist.c:(.text._nl_make_l10nflist+0x1f8): more undefined references to `stpcpy' follow
collect2: ld returned 1 exit status
make[3]: *** [xargs] Error 1
make[3]: Leaving directory `/COMPILE/FINDUTILS/findutils-4.1.20/xargs'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/COMPILE/FINDUTILS/findutils-4.1.20/xargs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/COMPILE/FINDUTILS/findutils-4.1.20'
make: *** [all] Error 2
23:16 findutils-4.1.20 # strip /COMPILE/FINDUTILS/findutils-4.1.20/find/find
23:25 findutils-4.1.20 # ls -s /COMPILE/FINDUTILS/findutils-4.1.20/find/find
92 /COMPILE/FINDUTILS/findutils-4.1.20/find/find
23:26 findutils-4.1.20 # file /COMPILE/FINDUTILS/findutils-4.1.20/find/find
/COMPILE/FINDUTILS/findutils-4.1.20/find/find: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
23:31 findutils-4.1.20 #
with outcommented lines for "stpcpy" at getline.h+.c , l10nflist.c , dcigettext.c and for "mbrtowc" at quotearg.c
This find is working though, but locate and xargs did not compile (as quoted above).
And find is still larger than the original initrd.gz-find.

Further it turned out that busybox more and less do not work in the rdsh like they use to at the prompt or in X normally : they rush to the very end of the file. e3 is already a very sophisticated and good editor but e3vi ( trying to exit e3vi with Ctrl-z) gave me a hang and the kernel did not reboot though i passed a panic=40 param to the grub commandline.
The busybox modinfo also needs two tweaks in the init-script :

Code: Select all

[ "`modinfo aufs | grep vermagic 2>/dev/null`" = "" ]
[ "`modinfo ppa | grep vermagic 2>/dev/null`" != "" ]
because busybox modinfo does not produce an error exit code if the module is not found .
Also the commands reboot,poweroff and halt do not work simply typed at the commandline. I'tll try again with umount -ar , fusermount -z -u , umount-FULL -i -n -l , kill 0 -3 -9 as it is mentioned at rc.shutdown.
waitmax and fsck are the only binaries that are not used by the scripts (e2fsck bianry is used) and bb-fsck hasn't got ext4 support.

Btw : Which version control system and licence to choose at code.google ? I have a few on skydrive at live/hotmail but to provide source for eg. kernels 50mb are not enough ( splitted into drivers and else ) and the navigation there is quite uncomfortable.

PANZERKOPF
Posts: 282
Joined: Wed 16 Dec 2009, 21:38
Location: Earth

#34 Post by PANZERKOPF »

Karl Godt wrote: And find is still larger than the original initrd.gz-find.
Because initrd's find is compressed with UPX.
e2fsck, resize2fs,fsck also are compressed with UPX.
You can see an UPX signature at offset 078h-07Ah.
SUUM CUIQUE.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#35 Post by technosaurus »

for stpcpy try adding -lcompat to the end of your LDFLAGS and or this in the includes of the referenced .c file
#include <string.h>

for mbrtowc try adding this to the list of includes
#include "dietlocale.h" //maybe
#include <wchar.h> //for sure
#include <errno.h> //maybe

maybe try this busybox patch pack that I cobbled together to use the old full e2fsprogs from various sources using chicken wire and duct tape.

Notes:
It has some compile warnings, but worked ok
Needs updated to new busybox constructs and ext4 support
I didn't add in the full usage text
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Post Reply