Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1430874
  • 博文数量: 613
  • 博客积分: 11499
  • 博客等级: 上将
  • 技术积分: 5511
  • 用 户 组: 普通用户
  • 注册时间: 2008-03-12 19:27
  • 认证徽章:
文章分类

全部博文(613)

文章存档

2016年(5)

2015年(18)

2014年(12)

2013年(16)

2012年(300)

2011年(45)

2010年(37)

2009年(79)

2008年(101)

分类: LINUX

2008-03-25 22:27:54




    在探讨Linux挂载根文件系统之后的流程时,制作了一个小的根文件系统作为分析的示例,结果因为共享库的问题,好长时间没有解决。从网上搜索了些资料,初步理解下,后续有时间再深入。
 

 
1、理解什么是目标代码,什么可执行代码,什么是库。
 
    编译之后生成的是二进制代码就是目标代码,它是不可以直接执行的。经过链接之后生成可执行代码,也就是可执行代码实际上是目标代码,操作系统的启动代码,库代码三者的总和。当然,不是简单的融合在一起,这个过程是比较复杂的,也就是链接器的作用了。
 
    由于目标代码,可执行代码都是操作系统相关的文件格式,所以是不兼容的。比如,Linux下不支持windows的exe可执行文件格式,windows也不支持Linux下的ELF可执行文件格式。
 
    库其实本质上也是可执行代码的二进制格式。库有三种使用形式:静态库、共享库、动态库。静态库供链接器使用,在链接时加载;共享库在链接时定位,在运行时 加载;动态库是共享库的另一种变化形式,也是在运行时加载,不过并非在程序运行开始时加载,而是在程序中的语句需要使用该函数时才载入。动态库可以在程序 运行期间释放动态库所占用的内存。
 
    Linux下的库文件分为共享库和静态库两大类。它们之间的差别就在于加载时刻不同,如上所述。区分库类型的方法就是看文件后缀,通常共享库以.so (shared object)结尾,而静态库通常以.a结尾(archive)。在终端缺省情况下,共享库通常为绿色,而静态库为黑色。
 
2、库的命名规则
 
    GNU的库的使用必须遵守Library GNU Public License(LGPL许可协议)。该协议和GNU许可协议略有不同,开发人员可以免费使用GNU库进行软件开发,但必须保证向用户提供所用的库函数的源代码。
 
    系统中可用的库默认存在在/usr/lib和/lib目录中。库文件名由前缀lib和库名以及后缀组成。根据库的类型不同,后缀名也不一样。共享库的后缀名由.so和版本号组成,静态库的后缀名为.a。采用旧的a.out格式的共享库的后缀名为.sa.
 
    libname.so.major.minor
    libname.a
 
    这里的name可以是任何字符串,用来唯一标识某个库。该字符串可以是一个单字、几个字符,甚至是一个字母。数学共享库的库名为libm.so.5,这里的标识字符为m,版本号为5.libm.a则是静态数学库。
 
3、自己的一些理解
 
    初步理解了链接器和加载器的原理,可以明白下面的规则:
 
    静态链接 --> 静态库 --> 链接时加载
    动态链接 --> 共享库 --> 链接时定位,运行时加载
 
    所以,很明显,如果是静态链接,则自动去寻找静态库。假定你指定了静态链接,而库路径下仅仅有相应的共享库文件,则依然提示找不到。对于静态链接程序而 言,所有目标文件都集中在一起而成为可执行文件,它不需要其他的支持就可以到兼容的系统中运行。正是因为所有的都集中,所以,静态编译的文件特别大,占用 空间就大。而嵌入式系统对空间要求比较苛刻,所以最好还是使用共享库。
 
    共享库在链接时只是定位,知道库的位置,在运行时才会载入库。这样,问题就来了,它怎么载入库呢?是通过共享库加载器来完成的。对于ELF文件,使用的共 享库加载器为ld-linux.so.2。所以,要想使用共享库,首先应该有ld-linux.so.2作为共享库加载器。那么,又产生的问题是:在运行 时如何找到共享库的位置呢?无论何时载入程序打算运行时,共享库都应该位于以下位置:
 
    (1)环境变量LD_LIBRARY_PATH列出的所有用分号分隔的位置
    (2)文件/etc/ld.so.cache中找到的库的列表,由工具ldconfig维护
    (3)目录/lib
    (4)目录/usr/lib
 
    如果我想要验证最小的根文件系统,那么最合适的方案就是:/bin /dev/ /lib /lost+found,bin下只有一个sh程序,dev下只有console,lib下存放sh的依赖共享库。只是实现了一个功能,就是打开一个 shell终端程序,只是不能做任何工作。如果采用静态链接制作sh,那么lib文件夹也可以不需要。这个制作没有实际意义,但是可以理解初始的流程。
 
    分析一下这个过程。大体的思路是,加载根文件系统,然后打开console,寻找第一个执行程序init,找到后就开始执行。具体看init/main.c中的init函数,基本初始化,完成命令行的解析后:
 

    if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
        printk(KERN_WARNING "Warning: unable to open an initial console.\n");

 
    所以,应该在/dev下包含console设备文件,否则的话,会出现无法打开初始化终端的提示。
 

    /*
     * We try each of these until one succeeds.
     *
     * The Bourne shell can be used instead of init if we are
     * trying to recover a really broken machine.
     */

    if (execute_command) {
        run_init_process(execute_command);
        printk(KERN_WARNING "Failed to execute %s. Attempting "
                    "defaults...\n", execute_command);

 
    这里的execute_command是一个全局变量,在解析传递进内核的命令行参数时确定的。
 

static int __init init_setup(char *str)
{
    unsigned int i;

    execute_command = str;
    
/*
     * In case LILO is going to boot us with default command line,
     * it prepends "auto" before the whole cmdline which makes
     * the shell think it should execute a script with such name.
     * So we ignore all arguments entered _before_ init=... [MJ]
     */

    for (i = 1; i < MAX_INIT_ARGS; i++)
        argv_init[i] = NULL;
    return 1;
}
__setup("init=", init_setup);

 
    这里的__setup是一个宏定义,比较复杂,定义在include/linux/init.h中。
 

#define __setup(str, fn)                    \
    __setup_param(str, fn, fn, 0)

 

#define __setup_param(str, unique_id, fn, early)            \
    static char __setup_str_##unique_id[] __initdata = str;    \
    static struct obs_kernel_param __setup_##unique_id    \
        __attribute_used__                \
        __attribute__((__section__(".init.setup")))    \
        __attribute__((aligned((sizeof(long)))))    \
        = { __setup_str_##unique_id, fn, early }

 
    这个利用了gcc的一些扩展用法,暂时忽略,来关注流程。就是如果你指定了init=filename,那么首先按照指定文件执行。如果没有指定,则要按照下列顺序依次执行:
 

    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.");

 
    可见,如果这四个位置都没有找到,或者找到文件,但是不可执行,那么就会产生kernel panic。而这个kernel panic是最为常见的一个错误提示了。
 
    分析到这里,也就清晰为什么最小的根文件系统会是这样了。具体制作步骤:
 
(1)制作一个ramdisk映象
 

dd if=/dev/zero of=if.img bs=1k count=15360
mke2fs -F -v -m0 if.img

 
    其中,of指定生成的映象的名字,bs是块的大小,count是ramdisk的大小,单位是KB。mke2fs是初始化ramdisk中的文件系统,完成后挂载后会出现lost+found文件夹。
 
(2)添加内容
 

|-- new
| |-- bin
| | |-- bash
| | `-- sh -> bash
| |-- dev
| | `-- console
| |-- lib
| | |-- ld-2.1.3.so
| | |-- ld-linux.so.2 -> ld-2.1.3.so
| | |-- libc-2.1.3.so
| | |-- libc.so.6 -> libc-2.1.3.so
| | |-- libtermcap.so.2 -> libtermcap.so.2.0.8
| | `-- libtermcap.so.2.0.8
| `-- lost+found

 
   这是制作的根文件系统的最小部分。其中,bash和lib里面的共享库是从开发板的ramdisk中摘出来的。至于bash是用了那些共享库,可以用 arm-linux-readelf查找,不过需要注意的是,前面工具没有列出ld-linux.so.2,而这个共享库加载器是必需的。在host下, 可以使用ldd查看可执行文件依赖的共享库,比较全面。原来的时候,ld-linux.so.2出现了问题,结果不管怎么修改,都会出现上面提到的那个 kernel panic,后来重新用了一个ld-linux.so.2,问题才消除。也说明,/etc/ld.so.conf和/etc/ld.so.cache并非 是必须的,在嵌入式系统中,你完全可以把需要用到的共享库放到/lib或者/usr/lib下面,这样就不需要设定LD_LIBRARY_PATH,也不 需要这两种/etc/下的配置文件了。不过应用多的情况下,为了区别,也可以使用上述两种方式添加库的查找路径。
 
(3)制作完成,并加载
 

[root@lqm fs]# umount new
[root@lqm fs]# gzip -c -v9 ramdisk > ramdisk.gz

 
    然后加载ramdisk.gz,最终效果:
 

RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 84K
bash#

 
    可见挂载根文件系统是正确的,可以识别ext2文件系统。然后打开了console,并且执行了/bin/sh。
 
    ramdisk映象备份如下,通过这个制作和分析过程,就比较清晰加载根文件系统后的初始过程。后面的完善功能定制,就完全依赖于shell脚本的配置和执行了。需要对这个过程进行更深入的分析和了解。
 
文件: ramdisk.rar
大小: 546KB
下载: 下载
阅读(530) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册