docs: ramdisk/initrd/initramfs corrections

- klibc, a userspace C library, currently packaged separately, that is

  optimized for correctness and small size.

The cpio file format used by initramfs is the "newc" (aka "cpio -c")

The cpio file format used by initramfs is the "newc" (aka "cpio -H newc")

format, and is documented in the file "buffer-format.txt".  There are

two ways to add an early userspace image: specify an existing cpio

archive to be used as the image or have the kernel build process build

CONFIG_INITRAMFS_SOURCE.  Sources can be either directories or files -

cpio archives are *not* allowed when building from sources.

A source directory will have it and all of it's contents packaged.  The

A source directory will have it and all of its contents packaged.  The

specified directory name will be mapped to '/'.  When packaging a

directory, limited user and group ID translation can be performed.

INITRAMFS_ROOT_UID can be set to a user ID that needs to be mapped to

   initrd format, an cpio archive.  It must be called "/init".  This binary

   is responsible to do all the things prepare_namespace() would do.

   To remain backwards compatibility, the /init binary will only run if it

   To maintain backwards compatibility, the /init binary will only run if it

   comes via an initramfs cpio archive.  If this is not the case,

   init/main.c:init() will run prepare_namespace() to mount the final root

   and exec one of the predefined init binaries.

Ramfs is a very simple filesystem that exports Linux's disk caching

mechanisms (the page cache and dentry cache) as a dynamically resizable

ram-based filesystem.

RAM-based filesystem.

Normally all files are cached in memory by Linux.  Pages of data read from

backing store (usually the block device the filesystem is mounted on) are kept

------------------

The older "ram disk" mechanism created a synthetic block device out of

an area of ram and used it as backing store for a filesystem.  This block

an area of RAM and used it as backing store for a filesystem.  This block

device was of fixed size, so the filesystem mounted on it was of fixed

size.  Using a ram disk also required unnecessarily copying memory from the

fake block device into the page cache (and copying changes back out), as well

to avoid this copying by playing with the page tables, but they're unpleasantly

complicated and turn out to be about as expensive as the copying anyway.)

More to the point, all the work ramfs is doing has to happen _anyway_,

since all file access goes through the page and dentry caches.  The ram

disk is simply unnecessary, ramfs is internally much simpler.

since all file access goes through the page and dentry caches.  The RAM

disk is simply unnecessary; ramfs is internally much simpler.

Another reason ramdisks are semi-obsolete is that the introduction of

loopback devices offered a more flexible and convenient way to create

    initramfs archive is a gzipped cpio archive (like tar only simpler,

    see cpio(1) and Documentation/early-userspace/buffer-format.txt).  The

    kernel's cpio extraction code is not only extremely small, it's also

    __init data that can be discarded during the boot process.

    __init text and data that can be discarded during the boot process.

  - The program run by the old initrd (which was called /initrd, not /init) did

    some setup and then returned to the kernel, while the init program from

non-GPL code you'd like to run from initramfs, without conflating it with

the GPL licensed Linux kernel binary).

It can also be used to supplement the kernel's built-in initamfs image.  The

It can also be used to supplement the kernel's built-in initramfs image.  The

files in the external archive will overwrite any conflicting files in

the built-in initramfs archive.  Some distributors also prefer to customize

a single kernel image with task-specific initramfs images, without recompiling.

The move to early userspace is necessary because finding and mounting the real

root device is complex.  Root partitions can span multiple devices (raid or

separate journal).  They can be out on the network (requiring dhcp, setting a

specific mac address, logging into a server, etc).  They can live on removable

specific MAC address, logging into a server, etc).  They can live on removable

media, with dynamically allocated major/minor numbers and persistent naming

issues requiring a full udev implementation to sort out.  They can be

compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,

----------------------

Recent kernels have support for populating a ramdisk from a compressed cpio

archive, on such systems, the creation of a ramdisk image doesn't need to

involve special block devices or loopbacks, you merely create a directory on

archive. On such systems, the creation of a ramdisk image doesn't need to

involve special block devices or loopbacks; you merely create a directory on

disk with the desired initrd content, cd to that directory, and run (as an

example):

generated with all the necessary modules. Then, only /sbin/init or a file

read by it would have to be different.

A third scenario are more convenient recovery disks, because information

A third scenario is more convenient recovery disks, because information

like the location of the root FS partition doesn't have to be provided at

boot time, but the system loaded from initrd can invoke a user-friendly

dialog and it can also perform some sanity checks (or even some form of

Mixed change_root and pivot_root mechanism

------------------------------------------

In case you did not want to use root=/dev/ram0 to trig the pivot_root mechanism,

you may create both /linuxrc and /sbin/init in your initrd image.

In case you did not want to use root=/dev/ram0 to trigger the pivot_root

mechanism, you may create both /linuxrc and /sbin/init in your initrd image.

/linuxrc would contain only the following:

umount -n /proc

Once linuxrc exited, the kernel would mount again your initrd as root,

this time executing /sbin/init. Again, it would be duty of this init

this time executing /sbin/init. Again, it would be the duty of this init

to build the right environment (maybe using the root= device passed on

the cmdline) before the final execution of the real /sbin/init.

RAM from the buffer cache. The driver marks the buffers it is using as dirty

so that the VM subsystem does not try to reclaim them later.

Also, the RAM disk supports up to 16 RAM disks out of the box, and can

be reconfigured to support up to 255 RAM disks - change "#define NUM_RAMDISKS"

in drivers/block/rd.c.  To use RAM disk support with your system, run

'./MAKEDEV ram' from the /dev directory.  RAM disks are all major number 1, and

start with minor number 0 for /dev/ram0, etc.  If used, modern kernels use

/dev/ram0 for an initrd.

The RAM disk supports up to 16 RAM disks by default, and can be reconfigured

to support an unlimited number of RAM disks (at your own risk).  Just change

the configuration symbol BLK_DEV_RAM_COUNT in the Block drivers config menu

and (re)build the kernel.

To use RAM disk support with your system, run './MAKEDEV ram' from the /dev

directory.  RAM disks are all major number 1, and start with minor number 0

for /dev/ram0, etc.  If used, modern kernels use /dev/ram0 for an initrd.

The old "ramdisk=<ram_size>" has been changed to "ramdisk_size=<ram_size>" to

make it clearer.  The original "ramdisk=<ram_size>" has been kept around for

compatibility reasons, but it may be removed in the future.

There are also config symbols (in the Block drivers config menu) for these

variables:  BLK_DEV_RAM_SIZE defaults to 4096 and BLK_DEV_RAM_BLOCKSIZE

defaults to 1024.

The new RAM disk also has the ability to load compressed RAM disk images,

allowing one to squeeze more programs onto an average installation or