Difference between revisions of "Ramdisk"

From LinuxMIPS
Jump to: navigation, search
m (See also: Fix link.)
 
(2 intermediate revisions by one other user not shown)
Line 41: Line 41:
 
</code>
 
</code>
  
So this will populate the initrd with a /dev directory, a <tt>/dev/console</tt> character device, a /root directory and ''most importantly'' a hello world program that does to <tt>/init</init> and control the further system initialization by sending a friendly greeting to the user. A more realistic scenario would be to have <tt>/init</tt> load important modules such as necessary device drivers and filesystems needed for further system initialization.  A big different between the old ramdisk scheme is that the filesystem that will be embedded into the kernel is a <tt>cpio</tt> archive, no longer the image of a filesystem on a block device.
+
So this will populate the initrd with a /dev directory, a <tt>/dev/console</tt> character device, a /root directory and ''most importantly'' a hello world program that does to <tt>/init</tt> and control the further system initialization by sending a friendly greeting to the user. A more realistic scenario would be to have <tt>/init</tt> load important modules such as necessary device drivers and filesystems needed for further system initialization.  A big different between the old ramdisk scheme is that the filesystem that will be embedded into the kernel is a <tt>cpio</tt> archive, no longer the image of a filesystem on a block device.
  
 
== Separate ramdisks ==
 
== Separate ramdisks ==
Starting in 2.6.10-rc2 the kernel accepts the two command line arguments <tt>rd_start</tt> and <tt>rd_size</tt>.  Both take a numeric argument and are used to pass the start address and size of a loaded ramdisk image to the kernel.  This interface is intended primarily for bootloaders in Linux distributions that want to retain the ability to create and modify ramdisks independant of kernels.
+
Starting in 2.6.10-rc2 the kernel accepts the two [[Kernel_Command_Line_Arguments | command line arguments]] <tt>rd_start</tt> and <tt>rd_size</tt>.  Both take a numeric argument and are used to pass the start address and size of a loaded ramdisk image to the kernel.  This interface is intended primarily for bootloaders in Linux distributions that want to retain the ability to create and modify ramdisks independant of kernels.
 +
 
 +
== See also ==
 +
* [http://www.linux-mips.org/git?p=ralf/linux.git;a=blob;f=Documentation/early-userspace/README Documentation/early-userspace/README]

Latest revision as of 19:45, 16 August 2012

The Linux ramdisk is primarily intended as an auxiliary filesystem for system initialization and installation. In some case where no other block device is available the entire root filesystem may reside on a ramdisk.

Embedded ramdisks

In Linux/MIPS 2.4 embedded ramdisks were introduced. With embedded ramdisk the ramdisk becomes part of the vmlinux binary. This type of ramdisk is particularly useful where having separate kernel and initrd image files would be inconvenient, for example where the firmware doesn't support this. The disadvantage of course is that replacing the ramdisk may require rebuilding the entire kernel.

Embedded ramdisk support is enabled by the CONFIG_EMBEDDED_RAMDISK configuration option. If this option is enabled EMBEDDED_RAMDISK_IMAGE has to be configured to the filename of a ramdisk image. Absolute filenames are permitted. Relative filenames are relative to arch/mips/ramdisk.

Embedded ramdisk support was removed for 2.6.10-rc2. The replacement is CONFIG_INITRAMFS_SOURCE. For your convience here's the kernel configuration help text:

     This can be set to either a directory containing files, etc to be
     included in the initramfs archive, or a file containing newline
     separated entries.

     If it is a file, it should be in the following format:
       # a comment
       file <name> <location> <mode> <uid> <gid>
       dir <name> <mode> <uid> <gid>
       nod <name> <mode> <uid> <gid> <dev_type> <maj> <min>

     Where:
       <name>      name of the file/dir/nod in the archive
       <location>  location of the file in the current filesystem
       <mode>      mode/permissions of the file
       <uid>       user id (0=root)
       <gid>       group id (0=root)
       <dev_type>  device type (b=block, c=character)
       <maj>       major number of nod
       <min>       minor number of nod

And here's a very simple example for such a file that describes an initramdisk:

   # This is a very simple initramfs

   dir /dev 0755 0 0
   nod /dev/console 0600 0 0 c 5 1
   dir /root 0700 0 0
   file /init /usr/src/hello-1.2/hello 0755 0 0

So this will populate the initrd with a /dev directory, a /dev/console character device, a /root directory and most importantly a hello world program that does to /init and control the further system initialization by sending a friendly greeting to the user. A more realistic scenario would be to have /init load important modules such as necessary device drivers and filesystems needed for further system initialization. A big different between the old ramdisk scheme is that the filesystem that will be embedded into the kernel is a cpio archive, no longer the image of a filesystem on a block device.

Separate ramdisks

Starting in 2.6.10-rc2 the kernel accepts the two command line arguments rd_start and rd_size. Both take a numeric argument and are used to pass the start address and size of a loaded ramdisk image to the kernel. This interface is intended primarily for bootloaders in Linux distributions that want to retain the ability to create and modify ramdisks independant of kernels.

See also