buffer-format.rst 4.7 KB

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