aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/filesystems
diff options
context:
space:
mode:
authorRob Landley <rob@landley.net>2006-01-08 04:03:43 -0500
committerLinus Torvalds <torvalds@g5.osdl.org>2006-01-08 23:14:00 -0500
commit99aef427e206f4ae7dcf0b18f66416145fea5d20 (patch)
treed4e478ce7b5a96ed283cbed67f2663ad488287f1 /Documentation/filesystems
parentd84f520348d77e61f936227a048403dbc349fff1 (diff)
[PATCH] update to the initramfs docs
Based on questions people have asked me. Repeatedly. Signed-off-by: Rob Landley <rob@landley.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'Documentation/filesystems')
-rw-r--r--Documentation/filesystems/ramfs-rootfs-initramfs.txt72
1 files changed, 71 insertions, 1 deletions
diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.txt b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
index b3404a032596..60ab61e54e8a 100644
--- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt
+++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
@@ -143,12 +143,26 @@ as the following example:
143 dir /mnt 755 0 0 143 dir /mnt 755 0 0
144 file /init initramfs/init.sh 755 0 0 144 file /init initramfs/init.sh 755 0 0
145 145
146Run "usr/gen_init_cpio" (after the kernel build) to get a usage message
147documenting the above file format.
148
146One advantage of the text file is that root access is not required to 149One advantage of the text file is that root access is not required to
147set permissions or create device nodes in the new archive. (Note that those 150set permissions or create device nodes in the new archive. (Note that those
148two example "file" entries expect to find files named "init.sh" and "busybox" in 151two example "file" entries expect to find files named "init.sh" and "busybox" in
149a directory called "initramfs", under the linux-2.6.* directory. See 152a directory called "initramfs", under the linux-2.6.* directory. See
150Documentation/early-userspace/README for more details.) 153Documentation/early-userspace/README for more details.)
151 154
155The kernel does not depend on external cpio tools, gen_init_cpio is created
156from usr/gen_init_cpio.c which is entirely self-contained, and the kernel's
157boot-time extractor is also (obviously) self-contained. However, if you _do_
158happen to have cpio installed, the following command line can extract the
159generated cpio image back into its component files:
160
161 cpio -i -d -H newc -F initramfs_data.cpio --no-absolute-filenames
162
163Contents of initramfs:
164----------------------
165
152If you don't already understand what shared libraries, devices, and paths 166If you don't already understand what shared libraries, devices, and paths
153you need to get a minimal root filesystem up and running, here are some 167you need to get a minimal root filesystem up and running, here are some
154references: 168references:
@@ -161,13 +175,69 @@ designed to be a tiny C library to statically link early userspace
161code against, along with some related utilities. It is BSD licensed. 175code against, along with some related utilities. It is BSD licensed.
162 176
163I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net) 177I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net)
164myself. These are LGPL and GPL, respectively. 178myself. These are LGPL and GPL, respectively. (A self-contained initramfs
179package is planned for the busybox 1.2 release.)
165 180
166In theory you could use glibc, but that's not well suited for small embedded 181In theory you could use glibc, but that's not well suited for small embedded
167uses like this. (A "hello world" program statically linked against glibc is 182uses like this. (A "hello world" program statically linked against glibc is
168over 400k. With uClibc it's 7k. Also note that glibc dlopens libnss to do 183over 400k. With uClibc it's 7k. Also note that glibc dlopens libnss to do
169name lookups, even when otherwise statically linked.) 184name lookups, even when otherwise statically linked.)
170 185
186Why cpio rather than tar?
187-------------------------
188
189This decision was made back in December, 2001. The discussion started here:
190
191 http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html
192
193And spawned a second thread (specifically on tar vs cpio), starting here:
194
195 http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html
196
197The quick and dirty summary version (which is no substitute for reading
198the above threads) is:
199
2001) cpio is a standard. It's decades old (from the AT&T days), and already
201 widely used on Linux (inside RPM, Red Hat's device driver disks). Here's
202 a Linux Journal article about it from 1996:
203
204 http://www.linuxjournal.com/article/1213
205
206 It's not as popular as tar because the traditional cpio command line tools
207 require _truly_hideous_ command line arguments. But that says nothing
208 either way about the archive format, and there are alternative tools,
209 such as:
210
211 http://freshmeat.net/projects/afio/
212
2132) The cpio archive format chosen by the kernel is simpler and cleaner (and
214 thus easier to create and parse) than any of the (literally dozens of)
215 various tar archive formats. The complete initramfs archive format is
216 explained in buffer-format.txt, created in usr/gen_init_cpio.c, and
217 extracted in init/initramfs.c. All three together come to less than 26k
218 total of human-readable text.
219
2203) The GNU project standardizing on tar is approximately as relevant as
221 Windows standardizing on zip. Linux is not part of either, and is free
222 to make its own technical decisions.
223
2244) Since this is a kernel internal format, it could easily have been
225 something brand new. The kernel provides its own tools to create and
226 extract this format anyway. Using an existing standard was preferable,
227 but not essential.
228
2295) Al Viro made the decision (quote: "tar is ugly as hell and not going to be
230 supported on the kernel side"):
231
232 http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html
233
234 explained his reasoning:
235
236 http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
237 http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html
238
239 and, most importantly, designed and implemented the initramfs code.
240
171Future directions: 241Future directions:
172------------------ 242------------------
173 243