[gobolinux-users] InitRamFS and cpio format

[Aitor Pérez Iturri]

El Mon, 28 May 2007 14:17:27 -0700
"Carlo Calica" <carlo at calica.com> escribió

> 
> How small can you get glibc?  Might be better to just have that rather
> than klibc, dietlibc, and glibc?  Do you have numbers on the relative
> sizes?

I choose dietlibc because it's easy to compile programs using this
command:
Compile Recipe -n Diet-Recipe -c CC="diet gcc -nostdinc"
i don't know how easy can be with other implementations or if they came
with any kind of wrapper to make things easy (klibc gives another
wrapper to do it).

I can give you some sizes:

From files included into the cpio file:

/lib
* 64572 klibc-rOj3PRLKBA9FcF5ZuoqKQLmOWcA.so

/bin
- Statically linked against dietlibc
* 597592 lvm

- Linked against klibc-rOj3PRLKBA9FcF5ZuoqKQLmOWcA.so
* 53828 ash
* 2264 cat
* 1052 ln
* 1676 mkdir
* 1416 mknod
* 1636 mount
* 828 reboot
* 1872 run-init
* 620 sleep
* 796 umount

- Statically linked against klibc
* 47868 udevstart

> Again size #'s would be useful.  I'd prefer to have actual udev (with
> our config files) rather than busybox's version.  It'll keep all dev
> names consistent then.  Does it generate /dev/disk/by-* entries
> correctly?
> 

About sizes, i can try to build alternative cpio images with different
glibc flavours (uclibc, dietlibc and klibc) to see how
many can they change, i think that uclibc is the most complete
impletentation today.

About udev, now i'm using the original udev compiled against klibc, it
can't generate /dev/disk/by* entries, because for that it needs
external programs (scsi_id, usb_id and so on). If we want to generate
the /dev population in the initramfs stage we will need another mount
implementation (now it comes from klibc sources) because current
doesn't allow --bind option to bind /dev
into /Root/System/Kernel/Devices (we can try with busybox mount or the
original mount maybe).

I think we must to choose with packages will come in the initramfs and
which glibc implementation to use.
I'm trying to compile now suspend against dietlibc but it has a lot of
errors at now.a

Tomorrow i will surfer google to see what implementation could be
better and i will try the next packages:
* UClibC
* Udev againts UClibc
* LVM against UClibc
* suspend against UClibc.
* Busybox against UClibc.

Any suggestion?

Greets.

Aitor.