用户工具

站点工具


jaysnote:ramfs_rootfs_initramfs

差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

两侧同时换到之前的修订记录 前一修订版
后一修订版 两侧同时换到之后的修订记录
jaysnote:ramfs_rootfs_initramfs [2018/11/19 13:51]
jaylee
jaysnote:ramfs_rootfs_initramfs [2018/11/19 15:18]
jaylee
行 49: 行 49:
   - The old initrd was always a separate file, while the initramfs archive is linked into the linux kernel image.  (The directory linux-*/usr is devoted to generating this archive during the build.)   - The old initrd was always a separate file, while the initramfs archive is linked into the linux kernel image.  (The directory linux-*/usr is devoted to generating this archive during the build.)
  
-  - The old initrd file was a gzipped filesystem image (in some file format, +  - The old initrd file was a gzipped filesystem image (in some file format,such as ext2, that needed a driver built into the kernel), while the new initramfs archive is a gzipped cpio archive (like tar only simpler,see cpio(1) and `Documentation/early-userspace/buffer-format.txt`).  The kernel's cpio extraction code is not only extremely small, it's also __init text and data that can be discarded during the boot process.
-    such as ext2, that needed a driver built into the kernel), while the new initramfs archive is a gzipped cpio archive (like tar only simpler, +
-    see cpio(1) and Documentation/early-userspace/buffer-format.txt).  The kernel's cpio extraction code is not only extremely small, it's also __init text and data that can be discarded during the boot process.+
  
   - The program run by the old initrd (which was called /initrd, not /init) did some setup and then returned to the kernel, while the init program from initramfs is not expected to return to the kernel.  (If /init needs to hand off control it can overmount / with a new root device and exec another init program.  See the switch_root utility, below.)   - The program run by the old initrd (which was called /initrd, not /init) did some setup and then returned to the kernel, while the init program from initramfs is not expected to return to the kernel.  (If /init needs to hand off control it can overmount / with a new root device and exec another init program.  See the switch_root utility, below.)
行 63: 行 61:
 The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary.  By default, this archive is empty (consuming 134 bytes on x86). The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary.  By default, this archive is empty (consuming 134 bytes on x86).
  
-The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig, +The config option **CONFIG_INITRAMFS_SOURCE** (in General Setup in menuconfig,and living in usr/Kconfig) can be used to specify a source for the initramfs archive, which will automatically be incorporated into the resulting binary.  This option can point to an existing gzipped cpio archive, a directory containing files to be archived, or a text file specification such as the following example:
-and living in usr/Kconfig) can be used to specify a source for the initramfs archive, which will automatically be incorporated into the resulting binary.  This option can point to an existing gzipped cpio archive, a directory containing files to be archived, or a text file specification such as the following example:+
  
 ```bash ```bash
行 79: 行 76:
 ``` ```
  
-Run "usr/gen_init_cpio" (after the kernel build) to get a usage message documenting the above file format.+Run `"usr/gen_init_cpio"(after the kernel build) to get a usage message documenting the above file format.
  
-One advantage of the configuration file is that root access is not required to set permissions or create device nodes in the new archive.  (Note that those two example "file" entries expect to find files named "init.sh" and "busybox" in a directory called "initramfs", under the linux-2.6.* directory.  See Documentation/early-userspace/README for more details.)+One advantage of the configuration file is that root access is not required to set permissions or create device nodes in the new archive.  (Note that those two example "file" entries expect to find files named "init.sh" and "busybox" in a directory called "initramfs", under the linux-2.6.* directory.  See `Documentation/early-userspace/READMEfor more details.)
  
-The kernel does not depend on external cpio tools.  If you specify a directory instead of a configuration file, the kernel's build infrastructure creates a configuration file from that directory (usr/Makefile calls scripts/gen_initramfs_list.sh), and proceeds to package up that directory using the config file (by feeding it to usr/gen_init_cpio, which is created from usr/gen_init_cpio.c).  The kernel's build-time cpio creation code is entirely self-contained, and the kernel's boot-time extractor is also +The kernel does not depend on external cpio tools.  If you specify a directory instead of a configuration file, the kernel's build infrastructure creates a configuration file from that directory (`usr/Makefilecalls `scripts/gen_initramfs_list.sh`), and proceeds to package up that directory using the config file (by feeding it to `usr/gen_init_cpio`, which is created from `usr/gen_init_cpio.c`).  The kernel's build-time cpio creation code is entirely self-contained, and the kernel's boot-time extractor is also (obviously) self-contained.
-(obviously) self-contained.+
  
-The one thing you might need external cpio utilities installed for is creating or extracting your own preprepared cpio files to feed to the kernel build +The one thing you might need external cpio utilities installed for is creating or extracting your own preprepared cpio files to feed to the kernel build (instead of a config file or directory).
-(instead of a config file or directory).+
  
 The following command line can extract a cpio image (either by the above script or by the kernel build) back into its component files: The following command line can extract a cpio image (either by the above script or by the kernel build) back into its component files:
行 153: 行 148:
  
 include <stdio.h> include <stdio.h>
- 
 include <unistd.h> include <unistd.h>
  
行 212: 行 206:
 "early userspace" (I.E. initramfs). "early userspace" (I.E. initramfs).
  
-The move to early userspace is necessary because finding and mounting the real root device is complex.  Root partitions can span multiple devices (raid or separate journal).  They can be out on the network (requiring dhcp, setting a specific MAC address, logging into a server, etc).  They can live on removable media, with dynamically allocated major/minor numbers and persistent naming issues requiring a full udev implementation to sort out.  They can be compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned, +The move to early userspace is necessary because finding and mounting the real root device is complex.  Root partitions can span multiple devices (raid or separate journal).  They can be out on the network (requiring dhcp, setting a specific MAC address, logging into a server, etc).  They can live on removable media, with dynamically allocated major/minor numbers and persistent naming issues requiring a full udev implementation to sort out.  They can be compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,and so on.
-and so on.+
  
 This kind of complexity (which inevitably includes policy) is rightly handled in userspace.  Both klibc and busybox/uClibc are working on simple initramfs packages to drop into a kernel build. This kind of complexity (which inevitably includes policy) is rightly handled in userspace.  Both klibc and busybox/uClibc are working on simple initramfs packages to drop into a kernel build.
jaysnote/ramfs_rootfs_initramfs.txt · 最后更改: 2021/06/22 23:14 (外部编辑)