Linux下 解包/打包 Android 映像文件 system.img, boot.img, ramdisk.img, userdata.img.

转自: http://blog.csdn.net/yulix/article/details/12968705

 

Android源码编译成功后会输出映像文件:system.img,boot.img, ramdisk.img,userdata.img等等。有时我们需要修改里面的内容,下面列出在Linux下如何解包/打包这些映像文件。

 

ramdisk.img

ramdisk.img是经cpio打包、并用gzip压缩的文件。

解包: 新建一个工作目录,把当前目录更改为该工作目录,执行下面命令(注意: img文件位置可能不同).

 

[plain] view plaincopy

  1. gunzip -c  $HOME/img/ramdisk.img | cpio -i

打包:在工作目录下,把该目录下的所有内容打包

[plain] view plaincopy

  1. find . | cpio -o -H newc | gzip > ../newramdisk.img

 

参考文档:  http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images

 

boot.img

boot.img包含2K字节头部,后面跟着的是zImage格式内核和和ramdisk格式的根文件系统。

解包工具: Android自带的unpackbootimg,以及一些脚本工具比如split_bootimg.pl

打包工具: Android自带的mkbootimg。

参考资料 :

中文请看: http://blog.csdn.net/wh_19910525/article/details/8200372

  英文请看:  http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images

system.img (EXT4)

 

system.img 是 sparse image格式文件,现有的mount命令无法直接处理。

我们得把sparse image格式转变为普通的img格式,Android源码中带的ext4_utils可以做这个,没有Android源码也不用担心,该工具的源代码已被剥离出来,可以自行下载编译,地址是:http://forum.xda-developers.com/showthread.php?t=1081239

我们得到工具有: simg2img,make_ext4fs等等:

解包:

 

[plain] view plaincopy

  1. simg2img system.img system.img.ext4
  2. mkdir mnt_dir
  3. sudo mount -t ext4 -o loop system.img.ext4 mnt_dir

打包:

[plain] view plaincopy

  1. sudo make_ext4fs -s -l 512M -a system system_new.img mnt_dir

注意:在我的机器上必须用root权限执行make_ext4fs,否则新生成的image文件无法使用。

 

 

userdata.img (EXT4)

 

和system.img(EXT4) 一样处理

Linux的概念与体系

作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明。谢谢!

 

我在这一系列文章中阐述Linux的基本概念。Linux操作系统继承自UNIX。一个操作系统是一套控制和使用计算机的软件。UNIX是一套规定,所有UNIX系统服从同一个的哲学体系。我侧重于Linux的宏观机制,而忽略许多技术细节。我想要展示Linux的骨架,提供一份辅助学习的Linux地图。无论是下层的内核,还是上层的具体操作和应用编程,都可以放入到这个框架中。写这个系列还有一个原因:之前写Python教程,发现Python的标准库有很大一部分,只不过是Python调用操作系统的接口。为了熟练的使用这些接口,操作系统的基础知识是不可或缺的。
希望这系列文章对大家有用。

 

我使用Linux Ubuntu 12.04,以此作为测试平台。

0. Linux简介与厂商版本

 
1. Linux开机启动

2. Linux文件管理

3. Linux的架构

4. Linux命令行与命令

5. Linux文件管理相关命令

6. Linux文本流

7. Linux进程基础

8. Linux信号基础

9. Linux进程关系

10. Linux用户

11. Linux从程序到进程

12. Linux多线程与同步

13. Linux进程间通信

14. Linux文件系统的实现

 

===============================================

补充:

Linux常用命令

 

如果你对Linux命令感兴趣,向你推荐

http://www.cnblogs.com/peida/archive/2012/12/05/2803591.html

作者是peida,他很认真的讲解了常用命令以及配置文件。

 

参考资料

参考书,见豆列:
http://book.douban.com/doulist/1663811/

linux 静态库、共享库

一、什么是库

本质上来说库是一种可执行代码的二进制形式,可以被操作系统载入内存执行。由于windows和linux的本质不同,因此二者库的二进制是不兼容的。
Linux操作系统支持的函数库分为静态库和动态库,动态库又称共享库。Linux系统有几个重要的目录存放相应的函数库,如/lib    /usr/lib。
二、静态函数库、动态函数库
A.  这类库的名字一般是libxxx.a;利用静态函数库编译成的文件比较大,因为整个函数库的所有数据都被整合进目标代码中,他的优点就显而易见了,即编译后的执行程序不需要外部的函数库支持,因为所有使用的函数都已经被编译进可执行文件了。当然这也会称为它的缺点,因为如果静态函数库改变了,那么你的程序必须重新编译,而且体积也较大。
B.这类库德名字一般是libxxx.so,动态库又称共享库;相对于静态函数库,动态函数库在编译的时候并没有被编译进目标代码中,你的程序执行到相关函数时才调用函数库里的相应函数,因此动态函数库所产生的可执行文件比较小。由于函数库没有被整合进你的程序,而是程序运行时动态申请并调用,所以程序的运行环境中必须提供相应的库。动态函数库的改变并不影响你的程序,所以动态函数库的升级比较方便。而且如果多个应用程序都要使用同一函数库,动态库就非常适合,可以减少应用程序的体积。
注意:不管是静态函数库还是动态函数库,都是由*.o目标文件生成。
三、函数库的创建
A.静态函数库的创建
ar -cr  libname.a   test1.o  test2.o
ar:静态函数库创建的命令
-c :create的意思
-r :replace的意思,表示当前插入的模块名已经在库中存在,则替换同名的模块。如果若干模块中有一个模块在库中不存在,ar显示一个错误信息,并不替换其他同名的模块。默认的情况下,新的成员增加在库德结尾处。
B.动态函数库的创建
gcc -shared  -fpic  -o libname.so  test1.c test2.c
-fpic:产生代码位置无关代码

-shared :生成共享库
四、静态库和动态库的使用
案例:
add.c
#include <stdio.h>
 
int add(int a,int b)
{
return a + b;
}
sub.c
#include <stdio.h>
 
int sub(int a,int b)
{
return a – b;
}
 
head.h
 
#ifndef _HEAD_H_
#define _HEAD_H_
extern int add(int a,int b);
extern int sub(int a,int b);
#endif
main.c
#include <stdio.h>
 
int main(int argc,char *argv[])
{
int a,b;
 
if(argc < 3)
{
fprintf(stderr,”Usage : %s argv[1] argv[2].\n”,argv[0]);
return -1;
}
a = atoi(argv[1]);
b = atoi(argv[2]);
 
printf(“a + b = %d\n”,add(a,b));
printf(“a – b = %d\n”,sub(a,b));
 
return 0;
}
生成静态库

生成动态库:

使用生成的生成的库:

其中
-L 指定函数库查找的位置,注意L后面还有’.’,表示在当前目录下查找
-l则指定函数库名,其中的lib和.a(.so)省略。
注意:-L是指定查找位置,-l指定需要操作的库名。
从上面的运行结果中,我们可以看到:
A.当动态库和静态库同时存在的时候,gcc默认使用的是动态库。如果强制使用静态库则需要加-static选项支持。
B.动态库生成的可执行文件,test1不能正常的运行。
C.链接静态库的可执行程序明显比链接动态库的可执行文件大。
五、让链接动态库的可执行程序正常运行。
当系统加载可执行代码时候,能够知道其所依赖的库的名字,但是还需要知道绝对路劲。此时就需要系统动态载入器(dynamic  linker/loader)。
对于elf格式的可执行程序,是由ld-linux.so*来完成的,它先后搜索elf文件的DT_RPATH段—环境变量LD_LIBRARY_PATH、/etc/ld.so.cache文件列表、/usr/lib、/lib目录找到库文件后将其载入内存。
A.一种最直接的方法,就是把生成的动态库拷贝到/usr/lib或/lib中去。

B.使用LD_LIBRARY_PATH环境变量,这个环境变量在ubuntu操作系统中默认没有,需要手动添加

C.动态在安装在其他目录下,如果想操作系统能找到它,可以通过一下步骤
<1>新建并编辑/etc/ld.so.conf.d/my.conf文件,加入库所在目录的路径
<2>执行ldconfig命令更新ld.so.cache文件

此时,在执行链接动态库的可执行文件则可以正常运行。
六、查看库中的符号
A.nm命令可以打印出库中涉及到的所有符号。库既可以是静态库也可以是动态的。
常见的三种符号:
<1>在库中被调用,但没有在库中定义(表明需要其他库支持),用U表示
<2>在库中定义的函数,用T表示
<3>“弱态”符号,他们虽然在库中被定义,但是可能被其他库中同名的符号覆盖,用W表示。

B.ldd命令可以查看一个可执行程序依赖的共享库

七、动态加载库
用gcc -shared生成的我们称为动态库(共享库),其中动态库在运行的过程中有两种方式
A.动态链接
这种方式下,可执行程序只是做一个动态的链接,当需要用到动态库中的函数时,有加载器隐士的加载。
B.动态加载
这种方式下,在可执行程序的内部,我们可以用dlopen()这样的函数,手动进行加载,dlsym()函数找到我们想要调用函数的入口地址,然后进行调用。这种方式,在写插件程序中得到广泛应用。
相关的API:

<1>dlopen()打开一个新的动态库,并把它装入内存。该函数主要用来记载库中的符号,这些符号在编译的时候是不知道的。
dlopen()函数需要两个参数:一个文件名和一个标志。
A.文件名是我们之前接触过的动态库的名字,如果它是一个绝对路径,如:/home/cyg/worddir/libname.so,此时dlopen直接到指定的路径下打开动态库。
如果没有指定路径,仅仅指定了一个动态库的名字,此时dlopen将它先后搜索elf文件的DT_RPATH段、环境变量LD_LIBRARY_PATH、/etc/ld.so.cache文件列表、/lib、/usr/lib目录找到库文件后将其载入内存。

B.标志指明是否立刻计算库的依赖性。

常常一个库中还依赖别的库,就是这个函数实现的时候,调用了别的库函数。不是在这个库中实现的函数我们称为位定义的符号。

如果将标志 设置为RTLD_NOW的话,则会在dlopen函数返回前,将这些未定义的符号解析出来。如果设置为RTLD_LAZY,则会在需要的时候才会去解析。
返回值:dlopen()函数会返回一个句柄作为dlsym()函数的第一个参数,以获得符号在库中的地址。使用这个地址,就可以获得库中特定函数的指针,并且调用装载库中的相应函数。
<2>dlerror()
当动态链接库操作函数执行失败时,dlerror可以返回出错信息,返回值为NULL时表示操作函数执行成功。
<3>void *dlsym(void *handle,char *symbol);
dlsym根据动态链接库操作句柄(handle)与符号(symbol),返回符号对应的函数的执行代码地址。由此地址,可以带参数执行相应的函数。
如程序代码 :int (*add)(int x,int y);//函数指针
handle = dlopen(“xxx.so”,RTLD_LAZY);//打开共享库
add = dlsym(handle,”add”);//获取add函数在共享库的地址
value = add(12,34);//调用add函数
<4>int dlclose(void *handle);
dlclose用于关闭指定句柄的动态链接库,只有当此动态链接库的使用计数为0时,才会真正被系统卸载。
案例:
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <dlfcn.h>
 
int test_dl(char *pso,char *pfu)
{
void *handle;
int (*ptest)(int x,int y);
 
if((handle = dlopen(pso,RTLD_LAZY)) == NULL)
{
printf(“%s.\n”,dlerror());
return -1;
}
if((ptest = dlsym(handle,pfu)) == NULL)
{
printf(“%s.\n”,dlerror());
return -1;
}
 
printf(“ptest complete : %d.\n”,ptest(12,13));
dlclose(handle);
 
return 0;
}
 
int main(int argc,char *argv[])
{
char buf[100];
char *pso,*pfun;
printf(“Input xxx.so:function_name.\n”);
while(1)
{
printf(“>”);
fgets(buf,sizeof(buf),stdin);
buf[strlen(buf)-1] = 0;
 
pso = strdup(strtok(buf,”:”));
pfun = strdup(strtok(NULL,”:”));
test_dl(pso,pfun);
}
return 0;
}
运行结果:

error while loading shared libraries: xxx.so.x”错误的原因和解决办法

一般我们在Linux下执行某些外部程序的时候可能会提示找不到共享库的错误, 比如:

 

tmux: error while loading shared libraries: libevent-1.4.so.2: cannot open shared object file: No such file or directory
原因一般有两个, 一个是操作系统里确实没有包含该共享库(lib*.so.*文件)或者共享库版本不对, 遇到这种情况那就去网上下载并安装上即可.

另外一个原因就是已经安装了该共享库, 但执行需要调用该共享库的程序的时候, 程序按照默认共享库路径找不到该共享库文件.

所以安装共享库后要注意共享库路径设置问题, 如下:

1) 如果共享库文件安装到了/lib或/usr/lib目录下, 那么需执行一下ldconfig命令

ldconfig命令的用途, 主要是在默认搜寻目录(/lib和/usr/lib)以及动态库配置文件/etc/ld.so.conf内所列的目录下, 搜索出可共享的动态链接库(格式如lib*.so*), 进而创建出动态装入程序(ld.so)所需的连接和缓存文件. 缓存文件默认为/etc/ld.so.cache, 此文件保存已排好序的动态链接库名字列表.

2) 如果共享库文件安装到了/usr/local/lib(很多开源的共享库都会安装到该目录下)或其它”非/lib或/usr/lib”目录下, 那么在执行ldconfig命令前, 还要把新共享库目录加入到共享库配置文件/etc/ld.so.conf中, 如下:

# cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
# echo “/usr/local/lib” >> /etc/ld.so.conf
# ldconfig

3) 如果共享库文件安装到了其它”非/lib或/usr/lib” 目录下,  但是又不想在/etc/ld.so.conf中加路径(或者是没有权限加路径). 那可以export一个全局变量LD_LIBRARY_PATH, 然后运行程序的时候就会去这个目录中找共享库. 

LD_LIBRARY_PATH的意思是告诉loader在哪些目录中可以找到共享库. 可以设置多个搜索目录, 这些目录之间用冒号分隔开. 比如安装了一个mysql到/usr/local/mysql目录下, 其中有一大堆库文件在/usr/local/mysql/lib下面, 则可以在.bashrc或.bash_profile或shell里加入以下语句即可:

export LD_LIBRARY_PATH=/usr/local/mysql/lib:$LD_LIBRARY_PATH

一般来讲这只是一种临时的解决方案, 在没有权限或临时需要的时候使用.

4)如果程序需要的库文件比系统目前存在的村文件版本低,可以做一个链接
比如:
error while loading shared libraries: libncurses.so.4: cannot open shared
object file: No such file or directory

ls /usr/lib/libncu*
/usr/lib/libncurses.a   /usr/lib/libncurses.so.5
/usr/lib/libncurses.so  /usr/lib/libncurses.so.5.3

可见虽然没有libncurses.so.4,但有libncurses.so.5,是可以向下兼容的
建一个链接就好了
ln -s  /usr/lib/libncurses.so.5.3  /usr/lib/libncurses.so.4

出处:http://blog.csdn.net/sahusoft/article/details/7388617
http://www.vrlinux.com/shujukuyingyong/20100407/26958.html

Linux命令之ar – 创建静态库.a文件

用途说明

创建静态库.a文件。用C/C++开发程序时经常用到,但我很少单独在命令行中使用ar命令,一般写在makefile中,有时也会在shell脚 本中用到。关于Linux下的库文件、静态库、动态库以及怎样创建和使用等相关知识,参见本文后面的相关资料【3】《关于Linux静态库和动态库的分析》。

 

常用参数

格式:ar rcs  libxxx.a xx1.o xx2.o

参数r:在库中插入模块(替换)。当插入的模块名已经在库中存在,则替换同名的模块。如果若干模块中有一个模块在库中不存在,ar显示一个错误消息,并不替换其他同名模块。默认的情况下,新的成员增加在库的结尾处,可以使用其他任选项来改变增加的位置。【1】

参数c:创建一个库。不管库是否存在,都将创建。

参数s:创建目标文件索引,这在创建较大的库时能加快时间。(补充:如果不需要创建索引,可改成大写S参数;如果.a文件缺少索引,可以使用ranlib命令添加)

 

格式:ar t libxxx.a

显示库文件中有哪些目标文件,只显示名称。

 

格式:ar tv libxxx.a

显示库文件中有哪些目标文件,显示文件名、时间、大小等详细信息。

 

格式:nm -s libxxx.a

显示库文件中的索引表。

 

格式:ranlib libxxx.a

为库文件创建索引表。

 

使用示例

示例一 在shell脚本中使用

 

Bash代码  收藏代码
  1. OS=`uname -r`
  2. ar rcs libhycu.a.$OS *.o

 

 

示例二 在makefile中使用

Makefile代码  收藏代码
  1. $(BIN1): $(BIN1_OBJS)
  2.         ar rcs $@ $^

 

 

示例三 创建并使用静态库

第一步:编辑源文件,test.h test.c main.c。其中main.c文件中包含main函数,作为程序入口;test.c中包含main函数中需要用到的函数。

vi test.h test.c main.c

第二步:将test.c编译成目标文件。

gcc -c test.c

如果test.c无误,就会得到test.o这个目标文件。

第三步:由.o文件创建静态库。

ar rcs libtest.a test.o

第四步:在程序中使用静态库。

gcc -o main main.c -L. -ltest

因为是静态编译,生成的执行文件可以独立于.a文件运行。

第五步:执行。

./main

 

示例四 创建并使用动态库

第一步:编辑源文件,test.h test.c main.c。其中main.c文件中包含main函数,作为程序入口;test.c中包含main函数中需要用到的函数。

vi test.h test.c main.c

第二步:将test.c编译成目标文件。

gcc -c test.c

前面两步与创建静态库一致。

第三步:由.o文件创建动态库文件。

gcc -shared -fPIC -o libtest.so test.o

第四步:在程序中使用动态库。

gcc -o main main.c -L. -ltest

当静态库和动态库同名时, gcc命令将优先使用动态库。

第五步:执行。

LD_LIBRARY_PATH=. ./main

 

示例五 查看静态库中的文件

[root@node56 lib]# ar -t libhycu.a
base64.c.o
binbuf.c.o
cache.c.o
chunk.c.o
codec_a.c.o

xort.c.o
[root@node56 lib]#
[root@node56 lib]# ar -tv libhycu.a
rw-r–r– 0/0   7220 Jul 29 19:18 2011 base64.c.o
rw-r–r– 0/0   2752 Jul 29 19:18 2011 binbuf.c.o
rw-r–r– 0/0  19768 Jul 29 19:18 2011 cache.c.o

rw-r–r– 0/0   4580 Jul 29 19:18 2011 xort.c.o
[root@node56 lib]#

[root@node56 lib]# nm -s libhycu.a | less

Archive index:
Base64Enc in base64.c.o
GetBase64Value in base64.c.o
Base64Dec in base64.c.o
encode64 in base64.c.o
decode64 in base64.c.o
check64 in base64.c.o
test64 in base64.c.o

chunk_alloc in chunk.c.o
[root@node56 lib]#

 

问题思考

相关资料

【1】CSDN文档中心  linux 的库操作命令 ar和nm

【2】linux ar 打包库到另一个库中[转]

【3】我的嵌入式设计家园 关于Linux静态库和动态库的分析

【4】Linux宝库 ar和nm命令的使用

 

内存分配的原理__进程分配内存有两种方式,分别由两个系统调用完成:brk和mmap(不考虑共享内存)。

如何查看进程发生缺页中断的次数

         用ps -o majflt,minflt -C program命令查看。

          majflt代表major fault,中文名叫大错误,minflt代表minor fault,中文名叫小错误

          这两个数值表示一个进程自启动以来所发生的缺页中断的次数

发成缺页中断后,执行了那些操作?

当一个进程发生缺页中断的时候,进程会陷入内核态,执行以下操作: 
1、检查要访问的虚拟地址是否合法
2、
查找/分配一个物理页
3、填充物理页内容(读取磁盘,或者直接置0,或者啥也不干)

4、建立映射关系(虚拟地址到物理地址)
重新执行发生缺页中断的那条指令
如果第3步,需要读取磁盘,那么这次缺页中断就是majflt,否则就是minflt。 

内存分配的原理

从操作系统角度来看,进程分配内存有两种方式,分别由两个系统调用完成:brk和mmap(不考虑共享内存)。

1、brk是将数据段(.data)的最高地址指针_edata往高地址推;

2、mmap是在进程的虚拟地址空间中(堆和栈中间,称为文件映射区域的地方)找一块空闲的虚拟内存

     这两种方式分配的都是虚拟内存,没有分配物理内存在第一次访问已分配的虚拟地址空间的时候,发生缺页中断,操作系统负责分配物理内存,然后建立虚拟内存和物理内存之间的映射关系。


在标准C库中,提供了malloc/free函数分配释放内存,这两个函数底层是由brk,mmap,munmap这些系统调用实现的。
下面以一个例子来说明内存分配的原理:

情况一、malloc小于128k的内存,使用brk分配内存,将_edata往高地址推(只分配虚拟空间,不对应物理内存(因此没有初始化),第一次读/写数据时,引起内核缺页中断,内核才分配对应的物理内存,然后虚拟地址空间建立映射关系),如下图:

内存分配的原理__进程分配内存有两种方式,分别由两个系统调用完成:brk和mmap(不考虑共享内存)。 - 无影 - 专注、坚持、思索
1、进程启动的时候,其(虚拟)内存空间的初始布局如图1所示。
      其中,mmap内存映射文件是在堆和栈的中间(例如libc-2.2.93.so,其它数据文件等),为了简单起见,省略了内存映射文件。
      _edata指针(glibc里面定义)指向数据段的最高地址。
2、进程调用A=malloc(30K)以后,内存空间如图2:
      malloc函数会调用brk系统调用,将_edata指针往高地址推30K,就完成虚拟内存分配。
      你可能会问:只要把_edata+30K就完成内存分配了?
      事实是这样的,_edata+30K只是完成虚拟地址的分配,A这块内存现在还是没有物理页与之对应的,等到进程第一次读写A这块内存的时候,发生缺页中断,这个时候,内核才分配A这块内存对应的物理页。也就是说,如果用malloc分配了A这块内容,然后从来不访问它,那么,A对应的物理页是不会被分配的。
3、
进程调用B=malloc(40K)以后,内存空间如图3。

情况二、malloc大于128k的内存,使用mmap分配内存,在堆和栈之间找一块空闲内存分配(对应独立内存,而且初始化为0),如下图:

内存分配的原理__进程分配内存有两种方式,分别由两个系统调用完成:brk和mmap(不考虑共享内存)。 - 无影 - 专注、坚持、思索
4、进程调用C=malloc(200K)以后,内存空间如图4:
      默认情况下,malloc函数分配内存,如果请求内存大于128K(可由M_MMAP_THRESHOLD选项调节),那就不是去推_edata指针了,而是利用mmap系统调用,从堆和栈的中间分配一块虚拟内存
      这样子做主要是因为::
      brk分配的内存需要等到高地址内存释放以后才能释放(例如,在B释放之前,A是不可能释放的,这就是内存碎片产生的原因,什么时候紧缩看下面),而mmap分配的内存可以单独释放。
      当然,还有其它的好处,也有坏处,再具体下去,有兴趣的同学可以去看glibc里面malloc的代码了。
5、进程调用D=malloc(100K)以后,内存空间如图5;
6、进程调用free(C)以后,C对应的虚拟内存和物理内存一起释放。
内存分配的原理__进程分配内存有两种方式,分别由两个系统调用完成:brk和mmap(不考虑共享内存)。 - 无影 - 专注、坚持、思索
7、进程调用free(B)以后,如图7所示:
        B对应的虚拟内存和物理内存都没有释放,因为只有一个_edata指针,如果往回推,那么D这块内存怎么办呢
当然,B这块内存,是可以重用的,如果这个时候再来一个40K的请求,那么malloc很可能就把B这块内存返回回去了
8、进程调用free(D)以后,如图8所示:
        B和D连接起来,变成一块140K的空闲内存。
9、默认情况下:
       当最高地址空间的空闲内存超过128K(可由M_TRIM_THRESHOLD选项调节)时,执行内存紧缩操作(trim)。在上一个步骤free的时候,发现最高地址空闲内存超过128K,于是内存紧缩,变成图9所示。

[转]Linux2.6 内核的 Initrd 机制解析

原始链接: https://www.ibm.com/developerworks/cn/linux/l-k26initrd/

Linux 的 initrd 技术是一个非常普遍使用的机制,linux2.6 内核的 initrd 的文件格式由原来的文件系统镜像文件转变成了 cpio 格式,变化不仅反映在文件格式上, linux 内核对这两种格式的 initrd 的处理有着截然的不同。本文首先介绍了什么是 initrd 技术,然后分别介绍了 Linux2.4 内核和 2.6 内核的 initrd 的处理流程。最后通过对 Linux2.6 内核的 initrd 处理部分代码的分析,使读者可以对 initrd 技术有一个全面的认识。为了更好的阅读本文,要求读者对 Linux 的 VFS 以及 initrd 有一个初步的了解。

2 评论:

李 大治 (dazhi.li@gmail.com), 软件工程师

2006 年 5 月 23 日

  • +内容

1.什么是 Initrd

initrd 的英文含义是 boot loader initialized RAM disk,就是由 boot loader 初始化的内存盘。在 linux内核启动前, boot loader 会将存储介质中的 initrd 文件加载到内存,内核启动时会在访问真正的根文件系统前先访问该内存中的 initrd 文件系统。在 boot loader 配置了 initrd 的情况下,内核启动被分成了两个阶段,第一阶段先执行 initrd 文件系统中的”某个文件”,完成加载驱动模块等任务,第二阶段才会执行真正的根文件系统中的 /sbin/init 进程。这里提到的”某个文件”,Linux2.6 内核会同以前版本内核的不同,所以这里暂时使用了”某个文件”这个称呼,后面会详细讲到。第一阶段启动的目的是为第二阶段的启动扫清一切障爱,最主要的是加载根文件系统存储介质的驱动模块。我们知道根文件系统可以存储在包括IDE、SCSI、USB在内的多种介质上,如果将这些设备的驱动都编译进内核,可以想象内核会多么庞大、臃肿。

Initrd 的用途主要有以下四种:

1. linux 发行版的必备部件

linux 发行版必须适应各种不同的硬件架构,将所有的驱动编译进内核是不现实的,initrd 技术是解决该问题的关键技术。Linux 发行版在内核中只编译了基本的硬件驱动,在安装过程中通过检测系统硬件,生成包含安装系统硬件驱动的 initrd,无非是一种即可行又灵活的解决方案。

2. livecd 的必备部件

同 linux 发行版相比,livecd 可能会面对更加复杂的硬件环境,所以也必须使用 initrd。

3. 制作 Linux usb 启动盘必须使用 initrd

usb 设备是启动比较慢的设备,从驱动加载到设备真正可用大概需要几秒钟时间。如果将 usb 驱动编译进内核,内核通常不能成功访问 usb 设备中的文件系统。因为在内核访问 usb 设备时, usb 设备通常没有初始化完毕。所以常规的做法是,在 initrd 中加载 usb 驱动,然后休眠几秒中,等待 usb设备初始化完毕后再挂载 usb 设备中的文件系统。

4. 在 linuxrc 脚本中可以很方便地启用个性化 bootsplash。

回页首

2.Linux2.4内核对 Initrd 的处理流程

为了使读者清晰的了解Linux2.6内核initrd机制的变化,在重点介绍Linux2.6内核initrd之前,先对linux2.4内核的initrd进行一个简单的介绍。Linux2.4内核的initrd的格式是文件系统镜像文件,本文将其称为image-initrd,以区别后面介绍的linux2.6内核的cpio格式的initrd。 linux2.4内核对initrd的处理流程如下:

1. boot loader把内核以及/dev/initrd的内容加载到内存,/dev/initrd是由boot loader初始化的设备,存储着initrd。

2. 在内核初始化过程中,内核把 /dev/initrd 设备的内容解压缩并拷贝到 /dev/ram0 设备上。

3. 内核以可读写的方式把 /dev/ram0 设备挂载为原始的根文件系统。

4. 如果 /dev/ram0 被指定为真正的根文件系统,那么内核跳至最后一步正常启动。

5. 执行 initrd 上的 /linuxrc 文件,linuxrc 通常是一个脚本文件,负责加载内核访问根文件系统必须的驱动, 以及加载根文件系统。

6. /linuxrc 执行完毕,真正的根文件系统被挂载。

7. 如果真正的根文件系统存在 /initrd 目录,那么 /dev/ram0 将从 / 移动到 /initrd。否则如果 /initrd 目录不存在, /dev/ram0 将被卸载。

8. 在真正的根文件系统上进行正常启动过程 ,执行 /sbin/init。 linux2.4 内核的 initrd 的执行是作为内核启动的一个中间阶段,也就是说 initrd 的 /linuxrc 执行以后,内核会继续执行初始化代码,我们后面会看到这是 linux2.4 内核同 2.6 内核的 initrd 处理流程的一个显著区别。

回页首

3.Linux2.6 内核对 Initrd 的处理流程

linux2.6 内核支持两种格式的 initrd,一种是前面第 3 部分介绍的 linux2.4 内核那种传统格式的文件系统镜像-image-initrd,它的制作方法同 Linux2.4 内核的 initrd 一样,其核心文件就是 /linuxrc。另外一种格式的 initrd 是 cpio 格式的,这种格式的 initrd 从 linux2.5 起开始引入,使用 cpio 工具生成,其核心文件不再是 /linuxrc,而是 /init,本文将这种 initrd 称为 cpio-initrd。尽管 linux2.6 内核对 cpio-initrd和 image-initrd 这两种格式的 initrd 均支持,但对其处理流程有着显著的区别,下面分别介绍 linux2.6 内核对这两种 initrd 的处理流程。

cpio-initrd 的处理流程

1. boot loader 把内核以及 initrd 文件加载到内存的特定位置。

2. 内核判断initrd的文件格式,如果是cpio格式。

3. 将initrd的内容释放到rootfs中。

4. 执行initrd中的/init文件,执行到这一点,内核的工作全部结束,完全交给/init文件处理。

image-initrd的处理流程

1. boot loader把内核以及initrd文件加载到内存的特定位置。

2. 内核判断initrd的文件格式,如果不是cpio格式,将其作为image-initrd处理。

3. 内核将initrd的内容保存在rootfs下的/initrd.image文件中。

4. 内核将/initrd.image的内容读入/dev/ram0设备中,也就是读入了一个内存盘中。

5. 接着内核以可读写的方式把/dev/ram0设备挂载为原始的根文件系统。

6. .如果/dev/ram0被指定为真正的根文件系统,那么内核跳至最后一步正常启动。

7. 执行initrd上的/linuxrc文件,linuxrc通常是一个脚本文件,负责加载内核访问根文件系统必须的驱动, 以及加载根文件系统。

8. /linuxrc执行完毕,常规根文件系统被挂载

9. 如果常规根文件系统存在/initrd目录,那么/dev/ram0将从/移动到/initrd。否则如果/initrd目录不存在, /dev/ram0将被卸载。

10. 在常规根文件系统上进行正常启动过程 ,执行/sbin/init。

通过上面的流程介绍可知,Linux2.6内核对image-initrd的处理流程同linux2.4内核相比并没有显著的变化, cpio-initrd的处理流程相比于image-initrd的处理流程却有很大的区别,流程非常简单,在后面的源代码分析中,读者更能体会到处理的简捷。

4.cpio-initrd同image-initrd的区别与优势

没有找到正式的关于cpio-initrd同image-initrd对比的文献,根据笔者的使用体验以及内核代码的分析,总结出如下三方面的区别,这些区别也正是cpio-initrd的优势所在:

cpio-initrd的制作方法更加简单

cpio-initrd的制作非常简单,通过两个命令就可以完成整个制作过程

#假设当前目录位于准备好的initrd文件系统的根目录下
bash# find . | cpio -c -o > ../initrd.img
bash# gzip ../initrd.img

而传统initrd的制作过程比较繁琐,需要如下六个步骤

#假设当前目录位于准备好的initrd文件系统的根目录下
bash# dd if=/dev/zero of=../initrd.img bs=512k count=5
bash# mkfs.ext2 -F -m0 ../initrd.img
bash# mount -t ext2 -o loop ../initrd.img  /mnt
bash# cp -r  * /mnt
bash# umount /mnt
bash# gzip -9 ../initrd.img

本文不对上面命令的含义作细节的解释,因为本文主要介绍的是linux内核对initrd的处理,对上面命令不理解的读者可以参考相关文档。

cpio-initrd的内核处理流程更加简化

通过上面initrd处理流程的介绍,cpio-initrd的处理流程显得格外简单,通过对比可知cpio-initrd的处理流程在如下两个方面得到了简化:

1. cpio-initrd并没有使用额外的ramdisk,而是将其内容输入到rootfs中,其实rootfs本身也是一个基于内存的文件系统。这样就省掉了ramdisk的挂载、卸载等步骤。

2. cpio-initrd启动完/init进程,内核的任务就结束了,剩下的工作完全交给/init处理;而对于image-initrd,内核在执行完/linuxrc进程后,还要进行一些收尾工作,并且要负责执行真正的根文件系统的/sbin/init。通过图1可以更加清晰的看出处理流程的区别:

图1内核对cpio-initrd和image-initrd处理流程示意图

图1内核对cpio-initrd和image-initrd处理流程示意图

cpio-initrd的职责更加重要

如图1所示,cpio-initrd不再象image-initrd那样作为linux内核启动的一个中间步骤,而是作为内核启动的终点,内核将控制权交给cpio-initrd的/init文件后,内核的任务就结束了,所以在/init文件中,我们可以做更多的工作,而不比担心同内核后续处理的衔接问题。当然目前linux发行版的cpio-initrd的/init文件的内容还没有本质的改变,但是相信initrd职责的增加一定是一个趋势。

回页首

5.linux2.6内核initrd处理的源代码分析

上面简要介绍了Linux2.4内核和2.6内核的initrd的处理流程,为了使读者对于Linux2.6内核的initrd的处理有一个更加深入的认识,下面将对Linuxe2.6内核初始化部分同initrd密切相关的代码给予一个比较细致的分析,为了讲述方便,进一步明确几个代码分析中使用的概念:

rootfs: 一个基于内存的文件系统,是linux在初始化时加载的第一个文件系统,关于它的进一步介绍可以参考文献[4]。

initramfs: initramfs同本文的主题关系不是很大,但是代码中涉及到了initramfs,为了更好的理解代码,这里对其进行简单的介绍。Initramfs是在 kernel 2.5中引入的技术,实际上它的含义就是:在内核镜像中附加一个cpio包,这个cpio包中包含了一个小型的文件系统,当内核启动时,内核将这个cpio包解开,并且将其中包含的文件系统释放到rootfs中,内核中的一部分初始化代码会放到这个文件系统中,作为用户层进程来执行。这样带来的明显的好处是精简了内核的初始化代码,而且使得内核的初始化过程更容易定制。Linux 2.6.12内核的 initramfs还没有什么实质性的东西,一个包含完整功能的initramfs的实现可能还需要一个缓慢的过程。对于initramfs的进一步了解可以参考文献[1][2][3]。

cpio-initrd: 前面已经定义过,指linux2.6内核使用的cpio格式的initrd。

image-initrd: 前面已经定义过,专指传统的文件镜像格式的initrd。

realfs: 用户最终使用的真正的文件系统。

内核的初始化代码位于 init/main.c 中的 static int init(void * unused)函数中。同initrd的处理相关部分函数调用层次如下图,笔者按照这个层次对每一个函数都给予了比较详细的分析,为了更好的说明,下面列出的代码中删除了同本文主题不相关的部分:

图2 initrd相关代码的调用层次关系图

图2 initrd相关代码的调用层次关系图init函数是内核所有初始化代码的入口,代码如下,其中只保留了同initrd相关部分的代码。

static int init(void * unused){
[1]	populate_rootfs();

[2]	if (sys_access((const char __user *) "/init", 0) == 0)
		execute_command = "/init";
	else
		prepare_namespace();
[3]	if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
		printk(KERN_WARNING "Warning: unable to open an initial console.\n");
	(void) sys_dup(0);
	(void) sys_dup(0);
[4]	if (execute_command)
		run_init_process(execute_command);
	run_init_process("/sbin/init");
	run_init_process("/etc/init");
	run_init_process("/bin/init");
	run_init_process("/bin/sh");
	panic("No init found.  Try passing init= option to kernel.");
}

代码[1]:populate_rootfs函数负责加载initramfs和cpio-initrd,对于populate_rootfs函数的细节后面会讲到。

代码[2]:如果rootfs的根目录下中包含/init进程,则赋予execute_command,在init函数的末尾会被执行。否则执行prepare_namespace函数,initrd是在该函数中被加载的。

代码[3]:将控制台设置为标准输入,后续的两个sys_dup(0),则复制标准输入为标准输出和标准错误输出。

代码[4]:如果rootfs中存在init进程,就将后续的处理工作交给该init进程。其实这段代码的含义是如果加载了cpio-initrd则交给cpio-initrd中的/init处理,否则会执行realfs中的init。读者可能会问:如果加载了cpio-initrd, 那么realfs中的init进程不是没有机会运行了吗?确实,如果加载了cpio-initrd,那么内核就不负责执行realfs的init进程了,而是将这个执行任务交给了cpio-initrd的init进程。解开fedora core4的initrd文件,会发现根目录的下的init文件是一个脚本,在该脚本的最后一行有这样一段代码:

………..
switchroot --movedev /sysroot

就是switchroot语句负责加载realfs,以及执行realfs的init进程。

对cpio-initrd的处理

对cpio-initrd的处理位于populate_rootfs函数中。

void __init populate_rootfs(void){
[1]  char *err = unpack_to_rootfs(__initramfs_start,
			 __initramfs_end - __initramfs_start, 0);
[2]	if (initrd_start) {
[3]		err = unpack_to_rootfs((char *)initrd_start,
			initrd_end - initrd_start, 1);

[4]		if (!err) {
			printk(" it is\n");
			unpack_to_rootfs((char *)initrd_start,
				initrd_end - initrd_start, 0);
			free_initrd_mem(initrd_start, initrd_end);
			return;
		}
[5]		fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
		if (fd >= 0) {
			sys_write(fd, (char *)initrd_start,
					initrd_end - initrd_start);
			sys_close(fd);
			free_initrd_mem(initrd_start, initrd_end);
		}
}

代码[1]:加载initramfs, initramfs位于地址__initramfs_start处,是内核在编译过程中生成的,initramfs的是作为内核的一部分而存在的,不是 boot loader加载的。前面提到了现在initramfs没有任何实质内容。

代码[2]:判断是否加载了initrd。无论哪种格式的initrd,都会被boot loader加载到地址initrd_start处。

代码[3]:判断加载的是不是cpio-initrd。实际上 unpack_to_rootfs有两个功能一个是释放cpio包,另一个就是判断是不是cpio包, 这是通过最后一个参数来区分的, 0:释放 1:查看。

代码[4]:如果是cpio-initrd则将其内容释放出来到rootfs中。

代码[5]:如果不是cpio-initrd,则认为是一个image-initrd,将其内容保存到/initrd.image中。在后面的image-initrd的处理代码中会读取/initrd.image。

对image-initrd的处理 在prepare_namespace函数里,包含了对image-initrd进行处理的代码,相关代码如下:

void __init prepare_namespace(void){
[1]	if (initrd_load())
		goto out;
out:
		umount_devfs("/dev");
[2]		sys_mount(".", "/", NULL, MS_MOVE, NULL);
		sys_chroot(".");
		security_sb_post_mountroot();
		mount_devfs_fs ();
}

代码[1]:执行initrd_load函数,将initrd载入,如果载入成功的话initrd_load函数会将realfs的根设置为当前目录。

代码[2]:将当前目录即realfs的根mount为Linux VFS的根。initrd_load函数执行完后,将真正的文件系统的根设置为当前目录。

initrd_load函数负责载入image-initrd,代码如下:

int __init initrd_load(void)
{
[1]	if (mount_initrd) {
		create_dev("/dev/ram", Root_RAM0, NULL);
[2]		if (rd_load_image("/initrd.image") && ROOT_DEV != Root_RAM0) {
			sys_unlink("/initrd.image");
			handle_initrd();
			return 1;
		}
	}
	sys_unlink("/initrd.image");
	return 0;
}

代码[1]:如果加载initrd则建立一个ram0设备 /dev/ram。

代码[2]:/initrd.image文件保存的就是image-initrd,rd_load_image函数执行具体的加载操作,将image-nitrd的文件内容释放到ram0里。判断ROOT_DEV!=Root_RAM0的含义是,如果你在grub或者lilo里配置了 root=/dev/ram0 ,则实际上真正的根设备就是initrd了,所以就不把它作为initrd处理 ,而是作为realfs处理。

handle_initrd()函数负责对initrd进行具体的处理,代码如下:

	static void __init handle_initrd(void){
[1]	real_root_dev = new_encode_dev(ROOT_DEV);
[2]	create_dev("/dev/root.old", Root_RAM0, NULL);
	mount_block_root("/dev/root.old", root_mountflags & ~MS_RDONLY);
[3]	sys_mkdir("/old", 0700);
	root_fd = sys_open("/", 0, 0);
	old_fd = sys_open("/old", 0, 0);
	/* move initrd over / and chdir/chroot in initrd root */
[4]	sys_chdir("/root");
	sys_mount(".", "/", NULL, MS_MOVE, NULL);
	sys_chroot(".");
	mount_devfs_fs ();
[5]	pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
	if (pid > 0) {
		while (pid != sys_wait4(-1, &i, 0, NULL))
			yield();
	}
	/* move initrd to rootfs' /old */
	sys_fchdir(old_fd);
	sys_mount("/", ".", NULL, MS_MOVE, NULL);
	/* switch root and cwd back to / of rootfs */
[6]	sys_fchdir(root_fd);
	sys_chroot(".");
	sys_close(old_fd);
	sys_close(root_fd);
	umount_devfs("/old/dev");
[7]	if (new_decode_dev(real_root_dev) == Root_RAM0) {
		sys_chdir("/old");
		return;
	}
[8]	ROOT_DEV = new_decode_dev(real_root_dev);
	mount_root();
[9]	printk(KERN_NOTICE "Trying to move old root to /initrd ... ");
	error = sys_mount("/old", "/root/initrd", NULL, MS_MOVE, NULL);
	if (!error)
		printk("okay\n");
	else {
		int fd = sys_open("/dev/root.old", O_RDWR, 0);
		printk("failed\n");
		printk(KERN_NOTICE "Unmounting old root\n");
		sys_umount("/old", MNT_DETACH);
		printk(KERN_NOTICE "Trying to free ramdisk memory ... ");
		if (fd < 0) {
			error = fd;
		} else {
			error = sys_ioctl(fd, BLKFLSBUF, 0);
			sys_close(fd);
		}
		printk(!error ? "okay\n" : "failed\n");
	}

handle_initrd函数的主要功能是执行initrd的linuxrc文件,并且将realfs的根目录设置为当前目录。

代码[1]:real_root_dev,是一个全局变量保存的是realfs的设备号。

代码[2]:调用mount_block_root函数将initrd文件系统挂载到了VFS的/root下。

代码[3]:提取rootfs的根的文件描述符并将其保存到root_fd。它的作用就是为了在chroot到initrd的文件系统,处理完initrd之后要,还能够返回rootfs。返回的代码参考代码[7]。

代码[4]:chroot进入initrd的文件系统。前面initrd已挂载到了rootfs的/root目录。

代码[5]:执行initrd的linuxrc文件,等待其结束。

代码[6]:initrd处理完之后,重新chroot进入rootfs。

代码[7]:如果real_root_dev在 linuxrc中重新设成Root_RAM0,则initrd就是最终的realfs了,改变当前目录到initrd中,不作后续处理直接返回。

代码[8]:在linuxrc执行完后,realfs设备已经确定,调用mount_root函数将realfs挂载到root_fs的 /root目录下,并将当前目录设置为/root。

代码[9]:后面的代码主要是做一些收尾的工作,将initrd的内存盘释放。

到此代码分析完毕。

回页首

6.结束语

通过本文前半部分对cpio-initrd和imag-initrd的阐述与对比以及后半部分的代码分析,我相信读者对Linux 2.6内核的initrd技术有了一个较为全面的了解。在本文的最后,给出两点最重要的结论:

1. 尽管Linux2.6既支持cpio-initrd,也支持image-initrd,但是cpio-initrd有着更大的优势,在使用中我们应该优先考虑使用cpio格式的initrd。

2. cpio-initrd相对于image-initrd承担了更多的初始化责任,这种变化也可以看作是内核代码的用户层化的一种体现,我们在其它的诸如FUSE等项目中也看到了将内核功能扩展到用户层实现的尝试。精简内核代码,将部分功能移植到用户层必然是linux内核发展的一个趋势。

回页首

参考资料

从下面三篇文章中,可以获得更多的关于initramfs的知识:

[1]http://tree.celinuxforum.org/pubwiki/moin.cgi/EarlyUserSpace

[2]http://lwn.net/Articles/14776/

[3]http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/0341.html

从下面这篇文章中读者可以了解到关于linux VSF、rootfs的相关知识:

[4] http://www.ibm.com/developerworks/cn/linux/l-vfs/

下面是一些initrd的参考资料:

[5] http://www.die.net/doc/linux/man/man4/initrd.4.html