diff options
author | Randy Dunlap <randy.dunlap@oracle.com> | 2007-10-17 02:29:29 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-10-17 11:42:56 -0400 |
commit | 1810732e94576ae0d04e953ecaba8c7151c9a287 (patch) | |
tree | c2ff43ec67ea41d2e5fee33b5e9a0d828871d3b5 | |
parent | 0e1ccb9619e8e9ae86dfc5a4645ccf3bf5a2eb3f (diff) |
docs: ramdisk/initrd/initramfs corrections
initrd/initramfs/ramdisk docs:
- fix typos/spellos/grammar
- clarify RAM disk config location
- correct cpio option
Acked-by: Bryan O'Sullivan <bos@serpentine.com>
Acked-by: Rob Landley <rob@landley.net>
Cc: Werner Almesberger <werner@almesberger.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-rw-r--r-- | Documentation/early-userspace/README | 6 | ||||
-rw-r--r-- | Documentation/filesystems/ramfs-rootfs-initramfs.txt | 14 | ||||
-rw-r--r-- | Documentation/initrd.txt | 12 | ||||
-rw-r--r-- | Documentation/ramdisk.txt | 17 |
4 files changed, 27 insertions, 22 deletions
diff --git a/Documentation/early-userspace/README b/Documentation/early-userspace/README index cddbac456c29..766d320c8eb6 100644 --- a/Documentation/early-userspace/README +++ b/Documentation/early-userspace/README | |||
@@ -19,7 +19,7 @@ It consists of several major infrastructure components: | |||
19 | - klibc, a userspace C library, currently packaged separately, that is | 19 | - klibc, a userspace C library, currently packaged separately, that is |
20 | optimized for correctness and small size. | 20 | optimized for correctness and small size. |
21 | 21 | ||
22 | The cpio file format used by initramfs is the "newc" (aka "cpio -c") | 22 | The cpio file format used by initramfs is the "newc" (aka "cpio -H newc") |
23 | format, and is documented in the file "buffer-format.txt". There are | 23 | format, and is documented in the file "buffer-format.txt". There are |
24 | two ways to add an early userspace image: specify an existing cpio | 24 | two ways to add an early userspace image: specify an existing cpio |
25 | archive to be used as the image or have the kernel build process build | 25 | archive to be used as the image or have the kernel build process build |
@@ -44,7 +44,7 @@ The image is specified as one or more sources in | |||
44 | CONFIG_INITRAMFS_SOURCE. Sources can be either directories or files - | 44 | CONFIG_INITRAMFS_SOURCE. Sources can be either directories or files - |
45 | cpio archives are *not* allowed when building from sources. | 45 | cpio archives are *not* allowed when building from sources. |
46 | 46 | ||
47 | A source directory will have it and all of it's contents packaged. The | 47 | A source directory will have it and all of its contents packaged. The |
48 | specified directory name will be mapped to '/'. When packaging a | 48 | specified directory name will be mapped to '/'. When packaging a |
49 | directory, limited user and group ID translation can be performed. | 49 | directory, limited user and group ID translation can be performed. |
50 | INITRAMFS_ROOT_UID can be set to a user ID that needs to be mapped to | 50 | INITRAMFS_ROOT_UID can be set to a user ID that needs to be mapped to |
@@ -144,7 +144,7 @@ c) using initramfs. The call to prepare_namespace() must be skipped. | |||
144 | initrd format, an cpio archive. It must be called "/init". This binary | 144 | initrd format, an cpio archive. It must be called "/init". This binary |
145 | is responsible to do all the things prepare_namespace() would do. | 145 | is responsible to do all the things prepare_namespace() would do. |
146 | 146 | ||
147 | To remain backwards compatibility, the /init binary will only run if it | 147 | To maintain backwards compatibility, the /init binary will only run if it |
148 | comes via an initramfs cpio archive. If this is not the case, | 148 | comes via an initramfs cpio archive. If this is not the case, |
149 | init/main.c:init() will run prepare_namespace() to mount the final root | 149 | init/main.c:init() will run prepare_namespace() to mount the final root |
150 | and exec one of the predefined init binaries. | 150 | and exec one of the predefined init binaries. |
diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.txt b/Documentation/filesystems/ramfs-rootfs-initramfs.txt index 25981e2e51be..339c6a4f220e 100644 --- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt | |||
@@ -8,7 +8,7 @@ What is ramfs? | |||
8 | 8 | ||
9 | Ramfs is a very simple filesystem that exports Linux's disk caching | 9 | Ramfs is a very simple filesystem that exports Linux's disk caching |
10 | mechanisms (the page cache and dentry cache) as a dynamically resizable | 10 | mechanisms (the page cache and dentry cache) as a dynamically resizable |
11 | ram-based filesystem. | 11 | RAM-based filesystem. |
12 | 12 | ||
13 | Normally all files are cached in memory by Linux. Pages of data read from | 13 | Normally all files are cached in memory by Linux. Pages of data read from |
14 | backing store (usually the block device the filesystem is mounted on) are kept | 14 | backing store (usually the block device the filesystem is mounted on) are kept |
@@ -34,7 +34,7 @@ ramfs and ramdisk: | |||
34 | ------------------ | 34 | ------------------ |
35 | 35 | ||
36 | The older "ram disk" mechanism created a synthetic block device out of | 36 | The older "ram disk" mechanism created a synthetic block device out of |
37 | an area of ram and used it as backing store for a filesystem. This block | 37 | an area of RAM and used it as backing store for a filesystem. This block |
38 | device was of fixed size, so the filesystem mounted on it was of fixed | 38 | device was of fixed size, so the filesystem mounted on it was of fixed |
39 | size. Using a ram disk also required unnecessarily copying memory from the | 39 | size. Using a ram disk also required unnecessarily copying memory from the |
40 | fake block device into the page cache (and copying changes back out), as well | 40 | fake block device into the page cache (and copying changes back out), as well |
@@ -46,8 +46,8 @@ unnecessary work for the CPU, and pollutes the CPU caches. (There are tricks | |||
46 | to avoid this copying by playing with the page tables, but they're unpleasantly | 46 | to avoid this copying by playing with the page tables, but they're unpleasantly |
47 | complicated and turn out to be about as expensive as the copying anyway.) | 47 | complicated and turn out to be about as expensive as the copying anyway.) |
48 | More to the point, all the work ramfs is doing has to happen _anyway_, | 48 | More to the point, all the work ramfs is doing has to happen _anyway_, |
49 | since all file access goes through the page and dentry caches. The ram | 49 | since all file access goes through the page and dentry caches. The RAM |
50 | disk is simply unnecessary, ramfs is internally much simpler. | 50 | disk is simply unnecessary; ramfs is internally much simpler. |
51 | 51 | ||
52 | Another reason ramdisks are semi-obsolete is that the introduction of | 52 | Another reason ramdisks are semi-obsolete is that the introduction of |
53 | loopback devices offered a more flexible and convenient way to create | 53 | loopback devices offered a more flexible and convenient way to create |
@@ -103,7 +103,7 @@ All this differs from the old initrd in several ways: | |||
103 | initramfs archive is a gzipped cpio archive (like tar only simpler, | 103 | initramfs archive is a gzipped cpio archive (like tar only simpler, |
104 | see cpio(1) and Documentation/early-userspace/buffer-format.txt). The | 104 | see cpio(1) and Documentation/early-userspace/buffer-format.txt). The |
105 | kernel's cpio extraction code is not only extremely small, it's also | 105 | kernel's cpio extraction code is not only extremely small, it's also |
106 | __init data that can be discarded during the boot process. | 106 | __init text and data that can be discarded during the boot process. |
107 | 107 | ||
108 | - The program run by the old initrd (which was called /initrd, not /init) did | 108 | - The program run by the old initrd (which was called /initrd, not /init) did |
109 | some setup and then returned to the kernel, while the init program from | 109 | some setup and then returned to the kernel, while the init program from |
@@ -220,7 +220,7 @@ device) but the separate packaging of initrd (which is nice if you have | |||
220 | non-GPL code you'd like to run from initramfs, without conflating it with | 220 | non-GPL code you'd like to run from initramfs, without conflating it with |
221 | the GPL licensed Linux kernel binary). | 221 | the GPL licensed Linux kernel binary). |
222 | 222 | ||
223 | It can also be used to supplement the kernel's built-in initamfs image. The | 223 | It can also be used to supplement the kernel's built-in initramfs image. The |
224 | files in the external archive will overwrite any conflicting files in | 224 | files in the external archive will overwrite any conflicting files in |
225 | the built-in initramfs archive. Some distributors also prefer to customize | 225 | the built-in initramfs archive. Some distributors also prefer to customize |
226 | a single kernel image with task-specific initramfs images, without recompiling. | 226 | a single kernel image with task-specific initramfs images, without recompiling. |
@@ -339,7 +339,7 @@ smooth transition and allowing early boot functionality to gradually move to | |||
339 | The move to early userspace is necessary because finding and mounting the real | 339 | The move to early userspace is necessary because finding and mounting the real |
340 | root device is complex. Root partitions can span multiple devices (raid or | 340 | root device is complex. Root partitions can span multiple devices (raid or |
341 | separate journal). They can be out on the network (requiring dhcp, setting a | 341 | separate journal). They can be out on the network (requiring dhcp, setting a |
342 | specific mac address, logging into a server, etc). They can live on removable | 342 | specific MAC address, logging into a server, etc). They can live on removable |
343 | media, with dynamically allocated major/minor numbers and persistent naming | 343 | media, with dynamically allocated major/minor numbers and persistent naming |
344 | issues requiring a full udev implementation to sort out. They can be | 344 | issues requiring a full udev implementation to sort out. They can be |
345 | compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned, | 345 | compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned, |
diff --git a/Documentation/initrd.txt b/Documentation/initrd.txt index d3dc505104da..74f68b35f7c1 100644 --- a/Documentation/initrd.txt +++ b/Documentation/initrd.txt | |||
@@ -80,8 +80,8 @@ Compressed cpio images | |||
80 | ---------------------- | 80 | ---------------------- |
81 | 81 | ||
82 | Recent kernels have support for populating a ramdisk from a compressed cpio | 82 | Recent kernels have support for populating a ramdisk from a compressed cpio |
83 | archive, on such systems, the creation of a ramdisk image doesn't need to | 83 | archive. On such systems, the creation of a ramdisk image doesn't need to |
84 | involve special block devices or loopbacks, you merely create a directory on | 84 | involve special block devices or loopbacks; you merely create a directory on |
85 | disk with the desired initrd content, cd to that directory, and run (as an | 85 | disk with the desired initrd content, cd to that directory, and run (as an |
86 | example): | 86 | example): |
87 | 87 | ||
@@ -293,7 +293,7 @@ information as small as possible. In this case, a common initrd could be | |||
293 | generated with all the necessary modules. Then, only /sbin/init or a file | 293 | generated with all the necessary modules. Then, only /sbin/init or a file |
294 | read by it would have to be different. | 294 | read by it would have to be different. |
295 | 295 | ||
296 | A third scenario are more convenient recovery disks, because information | 296 | A third scenario is more convenient recovery disks, because information |
297 | like the location of the root FS partition doesn't have to be provided at | 297 | like the location of the root FS partition doesn't have to be provided at |
298 | boot time, but the system loaded from initrd can invoke a user-friendly | 298 | boot time, but the system loaded from initrd can invoke a user-friendly |
299 | dialog and it can also perform some sanity checks (or even some form of | 299 | dialog and it can also perform some sanity checks (or even some form of |
@@ -339,8 +339,8 @@ the new, supported mechanism is called "pivot_root". | |||
339 | Mixed change_root and pivot_root mechanism | 339 | Mixed change_root and pivot_root mechanism |
340 | ------------------------------------------ | 340 | ------------------------------------------ |
341 | 341 | ||
342 | In case you did not want to use root=/dev/ram0 to trig the pivot_root mechanism, | 342 | In case you did not want to use root=/dev/ram0 to trigger the pivot_root |
343 | you may create both /linuxrc and /sbin/init in your initrd image. | 343 | mechanism, you may create both /linuxrc and /sbin/init in your initrd image. |
344 | 344 | ||
345 | /linuxrc would contain only the following: | 345 | /linuxrc would contain only the following: |
346 | 346 | ||
@@ -350,7 +350,7 @@ echo 0x0100 >/proc/sys/kernel/real-root-dev | |||
350 | umount -n /proc | 350 | umount -n /proc |
351 | 351 | ||
352 | Once linuxrc exited, the kernel would mount again your initrd as root, | 352 | Once linuxrc exited, the kernel would mount again your initrd as root, |
353 | this time executing /sbin/init. Again, it would be duty of this init | 353 | this time executing /sbin/init. Again, it would be the duty of this init |
354 | to build the right environment (maybe using the root= device passed on | 354 | to build the right environment (maybe using the root= device passed on |
355 | the cmdline) before the final execution of the real /sbin/init. | 355 | the cmdline) before the final execution of the real /sbin/init. |
356 | 356 | ||
diff --git a/Documentation/ramdisk.txt b/Documentation/ramdisk.txt index 52f75b7d51c2..33e987df071e 100644 --- a/Documentation/ramdisk.txt +++ b/Documentation/ramdisk.txt | |||
@@ -22,16 +22,21 @@ The RAM disk dynamically grows as more space is required. It does this by using | |||
22 | RAM from the buffer cache. The driver marks the buffers it is using as dirty | 22 | RAM from the buffer cache. The driver marks the buffers it is using as dirty |
23 | so that the VM subsystem does not try to reclaim them later. | 23 | so that the VM subsystem does not try to reclaim them later. |
24 | 24 | ||
25 | Also, the RAM disk supports up to 16 RAM disks out of the box, and can | 25 | The RAM disk supports up to 16 RAM disks by default, and can be reconfigured |
26 | be reconfigured to support up to 255 RAM disks - change "#define NUM_RAMDISKS" | 26 | to support an unlimited number of RAM disks (at your own risk). Just change |
27 | in drivers/block/rd.c. To use RAM disk support with your system, run | 27 | the configuration symbol BLK_DEV_RAM_COUNT in the Block drivers config menu |
28 | './MAKEDEV ram' from the /dev directory. RAM disks are all major number 1, and | 28 | and (re)build the kernel. |
29 | start with minor number 0 for /dev/ram0, etc. If used, modern kernels use | 29 | |
30 | /dev/ram0 for an initrd. | 30 | To use RAM disk support with your system, run './MAKEDEV ram' from the /dev |
31 | directory. RAM disks are all major number 1, and start with minor number 0 | ||
32 | for /dev/ram0, etc. If used, modern kernels use /dev/ram0 for an initrd. | ||
31 | 33 | ||
32 | The old "ramdisk=<ram_size>" has been changed to "ramdisk_size=<ram_size>" to | 34 | The old "ramdisk=<ram_size>" has been changed to "ramdisk_size=<ram_size>" to |
33 | make it clearer. The original "ramdisk=<ram_size>" has been kept around for | 35 | make it clearer. The original "ramdisk=<ram_size>" has been kept around for |
34 | compatibility reasons, but it may be removed in the future. | 36 | compatibility reasons, but it may be removed in the future. |
37 | There are also config symbols (in the Block drivers config menu) for these | ||
38 | variables: BLK_DEV_RAM_SIZE defaults to 4096 and BLK_DEV_RAM_BLOCKSIZE | ||
39 | defaults to 1024. | ||
35 | 40 | ||
36 | The new RAM disk also has the ability to load compressed RAM disk images, | 41 | The new RAM disk also has the ability to load compressed RAM disk images, |
37 | allowing one to squeeze more programs onto an average installation or | 42 | allowing one to squeeze more programs onto an average installation or |