[klibc] Query regarding initramfs

[Andreas Jellinghaus]

On Tue, 2005-03-29 at 19:41 +0530, Rachita Kothiyal wrote:
> Hi
> 
> 1. Had one more basic query, how are initrd and initramfs different ?
> 
> Of what I understand, the following are the differnces:
> 
> a. initrd's format is ext2 filesysstem(compressed)

any filesystem will do, as long as the kernels autodetection
can detect it. 

the compression is optional.

> while that of initramfs is compressed cpio(newc) archive.

the compression is optional.

initrd is also used at name for the whole technology to execute some
code before the real root is mounted and executed. it's defined by code
that evolved over time, so there is no sharp definition.

> 2. How is initramfs better over initrd? Isnt it just redundant? What are we
> achiveing by initramfs that initrd does not provide ?

I'm not 100% sure why initrd was developed, but it solves two problems:
pass a filesystem in ram to a kernel, so it doesn't need a medium, and
allow drivers for everything, including the hardware for the device with
the root filesystem to be compiled as module and only load the modules
needed.

initrd is - for whatever reasons - not attractive enough, so people
did not dump code that is currently in the kernel and thus in the
kernel binary, but could be in a user space application: dhcp/bootp
client, firmware loader, some setup routines. I guess the basic
requirement is not to have a degression, i.e. the final result must
be one binary that is loaded by the bootload and does have that
functionality (e.g. bootp/dhcp, mount nfs root fs, ...). so if that
code is moved to userspace, how can userspace code be in the vmlinuz
file? I have no idea if that is possible with initrd, but it is 
possible with initramfs, and as such initramfs has one feature more
than initrd.

about prepare_namespace(): I guess that is code that could be used
at least in parts to an application on the initramfs, since that code
is never used again after booting.

at least as far as I understand, the intention of the kernel developer
is to get rid of many small code fragements that are in the kernel only
for historical reasons, but a clean re-design with the current
infrastructure in the kernel would put them into user space. initramfs
and klibc are two vehicles to do that.

> 3. Like in the case of initramfs, even in the case of initrd, it is mounted
> as root. Then why do we pass root=/dev/initrd in case of initramfs while
> root=<root_device> incase of initrd?

If I haven't misread the source code, initramfs will be started
independend of and "root=" and "init=" command line arguments.
I guess the code to look at these command line arguments should be
better move to user space and an application within initramfs, too.

Regards, Andreas


-- 
---------------------[ Ciphire Signature ]----------------------
From: aj at ciphirelabs.com signed email body (2232 characters)
Date: on 29 March 2005 at 15:45:09 UTC
To:   rachitako at in.ibm.com, klibc at zytor.com
----------------------------------------------------------------
: Ciphire has secured this email against identity theft.
: Free download at www.ciphire.com. The garbled lines
: below are the sender's verifiable digital signature.
----------------------------------------------------------------
00fAAAAAEAAAAFeElCuAgAAEUCAAIAAgACACCFlK4A+54we7zwPJsjFBflkYBMj+
KIfUWI8cEb4zJitwEAjuLZDHPnOxRgKfQyXaVwrQqQB78iLphbN7mW+8mUnEF2KO
/OVy+75ObsMaqROOwPPVhYZ6xvxTuYGwSIjo2rvQ==
------------------[ End Ciphire Signed Message ]----------------