Blame view

Documentation/early-userspace/buffer-format.txt 4.5 KB
1da177e4c   Linus Torvalds   Linux-2.6.12-rc2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
  		       initramfs buffer format
  		       -----------------------
  
  		       Al Viro, H. Peter Anvin
  		      Last revision: 2002-01-13
  
  Starting with kernel 2.5.x, the old "initial ramdisk" protocol is
  getting {replaced/complemented} with the new "initial ramfs"
  (initramfs) protocol.  The initramfs contents is passed using the same
  memory buffer protocol used by the initrd protocol, but the contents
  is different.  The initramfs buffer contains an archive which is
  expanded into a ramfs filesystem; this document details the format of
  the initramfs buffer format.
  
  The initramfs buffer format is based around the "newc" or "crc" CPIO
  formats, and can be created with the cpio(1) utility.  The cpio
  archive can be compressed using gzip(1).  One valid version of an
  initramfs buffer is thus a single .cpio.gz file.
  
  The full format of the initramfs buffer is defined by the following
  grammar, where:
  	*	is used to indicate "0 or more occurrences of"
  	(|)	indicates alternatives
  	+	indicates concatenation
  	GZIP()	indicates the gzip(1) of the operand
  	ALGN(n)	means padding with null bytes to an n-byte boundary
  
  	initramfs  := ("\0" | cpio_archive | cpio_gzip_archive)*
  
  	cpio_gzip_archive := GZIP(cpio_archive)
  
  	cpio_archive := cpio_file* + (<nothing> | cpio_trailer)
  
  	cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data
  
  	cpio_trailer := ALGN(4) + cpio_header + "TRAILER!!!\0" + ALGN(4)
  
  
  In human terms, the initramfs buffer contains a collection of
  compressed and/or uncompressed cpio archives (in the "newc" or "crc"
  formats); arbitrary amounts zero bytes (for padding) can be added
  between members.
  
  The cpio "TRAILER!!!" entry (cpio end-of-archive) is optional, but is
  not ignored; see "handling of hard links" below.
  
  The structure of the cpio_header is as follows (all fields contain
  hexadecimal ASCII numbers fully padded with '0' on the left to the
  full width of the field, for example, the integer 4780 is represented
  by the ASCII string "000012ac"):
  
  Field name    Field size	 Meaning
  c_magic	      6 bytes		 The string "070701" or "070702"
  c_ino	      8 bytes		 File inode number
  c_mode	      8 bytes		 File mode and permissions
  c_uid	      8 bytes		 File uid
  c_gid	      8 bytes		 File gid
  c_nlink	      8 bytes		 Number of links
  c_mtime	      8 bytes		 Modification time
  c_filesize    8 bytes		 Size of data field
  c_maj	      8 bytes		 Major part of file device number
  c_min	      8 bytes		 Minor part of file device number
  c_rmaj	      8 bytes		 Major part of device node reference
  c_rmin	      8 bytes		 Minor part of device node reference
  c_namesize    8 bytes		 Length of filename, including final \0
  c_chksum      8 bytes		 Checksum of data field if c_magic is 070702;
  				 otherwise zero
  
  The c_mode field matches the contents of st_mode returned by stat(2)
  on Linux, and encodes the file type and file permissions.
  
  The c_filesize should be zero for any file which is not a regular file
  or symlink.
  
  The c_chksum field contains a simple 32-bit unsigned sum of all the
  bytes in the data field.  cpio(1) refers to this as "crc", which is
  clearly incorrect (a cyclic redundancy check is a different and
  significantly stronger integrity check), however, this is the
  algorithm used.
  
  If the filename is "TRAILER!!!" this is actually an end-of-archive
  marker; the c_filesize for an end-of-archive marker must be zero.
  
  
  *** Handling of hard links
  
  When a nondirectory with c_nlink > 1 is seen, the (c_maj,c_min,c_ino)
  tuple is looked up in a tuple buffer.  If not found, it is entered in
  the tuple buffer and the entry is created as usual; if found, a hard
  link rather than a second copy of the file is created.  It is not
  necessary (but permitted) to include a second copy of the file
  contents; if the file contents is not included, the c_filesize field
  should be set to zero to indicate no data section follows.  If data is
  present, the previous instance of the file is overwritten; this allows
  the data-carrying instance of a file to occur anywhere in the sequence
  (GNU cpio is reported to attach the data to the last instance of a
  file only.)
  
  c_filesize must not be zero for a symlink.
  
  When a "TRAILER!!!" end-of-archive marker is seen, the tuple buffer is
  reset.  This permits archives which are generated independently to be
  concatenated.
  
  To combine file data from different sources (without having to
  regenerate the (c_maj,c_min,c_ino) fields), therefore, either one of
  the following techniques can be used:
  
  a) Separate the different file data sources with a "TRAILER!!!"
     end-of-archive marker, or
  
  b) Make sure c_nlink == 1 for all nondirectory entries.