kernel参数 linux

2019-03-06 10:32:18 weixin_40756041 阅读数 3692

Linux内核更新是越来越快了,可能由于Linux的普及,大家都开始关注了,各种安全隐患也越来越多。支持Intel、Alpha、PPC、Sparc、IA-64、ARM、MIPS、Amiga、Atari和IBMs/390等,还支持32位大文件系统。而在Intel平台上,物理内存最大支持可以达到64GB。加强对IDE和SCSI硬件系统的支持,并增强了对USB设备和3D加速卡的支持。下面向大家详细介绍LinuxKernel。

    牛津字典中对"kernel"一词的定义是:"较软的、通常是一个坚果可食用的部分。"当然还有第二种定义:"某个东西核心或者最重要的部分。"对Linux来说,它的Kernel无疑属于第二种解释。让我们来看看这个重要的东西是如何工作的,先从一点理论说起。

    广义地来说kernel就是一个软件,它在硬件和运行在计算机上的应用程序之间提供了一个层。严格点从计算机科学的角度来说,Linux中的Kernel指的是Linus Torvalds在90年代初期写的那点代码。

    所有的你在Linux各版本中看到的其他东西--Bash shell、KDE窗口管理器、web浏览器、X服务器、Tux Racer以及所有的其他,都不过是运行在Linux上的应用而已,而不是操作系统自身的一部分。为了给大家一个更加直观的感觉,我来举个例子,比如RHEL5的安装大概要占据2.5GB的硬盘空间(具体多大当然视你的选择安装来定),在这其中,kernel以及它的各个模块组件,只有47MB,所占比例约为2%。
 

在kernel内部

    那么kernel到底是如何工作的呢?如下面的图表。Kernel通过许多的进入端口也就是我们从技术角度所说的系统调用,来使得运行在它上面的应用程序可用。Kernel使用的系统调用比如"读"和"写"来提供你硬件的抽象(abstraction)。

    从程序员的视角来看,这些看起来只是普通的功能调用,然而实际上系统调用在处理器的操作模式上,从用户空间到Kernel空间有一个明显的切换。同时,系统调用提供了一个"Linux虚拟机",可以被认为是对硬件的抽象。

    Kernel提供的更明显的抽象之一是文件系统。举例来说,这里有一段短的程序是用C写的,它打开了一个文件并将内容拷贝到标准的输出:

    #include <fcntl.h>
    int main()
    {
        int fd, count; char buf[1000];
        fd=open("mydata", O_RDONLY);
        count = read(fd, buf, 1000);
        write(1, buf, count);
        close(fd);
    }

台前幕后    在这里,你可以看到四个系统调用的例子:打开、读、写和关闭。不谈这段程序语法的细节,重点是:通过这些系统调用Linux Kernel提供了一个文件的"错觉",而实际上它不过是一堆数据有了个名字,这样一来你就不必去与硬件底层的堆栈、分区、头和指针、分区等交涉了,而是直接以例子中的方式与硬件"交流",这也就是我们所说的抽象(abstraction),将底层的东西以更易懂的方式表达出来。
    系统文件是Kernel提供的较为明显的一种抽象。还有一些特性不是这么的明显,比如进程调度。任何一个时间,都可能有好几个进程或者程序等待着运行。Kernel的时间调度给每个进程分配CPU时间,所以就一段时间内来说,我们会有种错觉:电脑同一时间运行好几个程序。这是另外一个C程序:

    #include <stdlib.h>
    main()
    {
      if (fork()) {
        write(1, "Parent\n", 7);
        wait(0);
        exit(0);
      }
      else {
        write(1, "Child\n", 6);
        exit(0);
      }
    }

 

    在这个程序中创建了一个新进程,而原来的进程(父进程)和新进程(子进程)都编写了标准输出然后结束。注意系统调用fork(), exit() 以及 wait()执行程序的创建、结束和各自同步。这是进程管理和调度中最典型的简单调用。

    Kernel还有一个更加不易见到的功能,连程序员都不易察觉,那就是存储管理。每个程序运行得都好像它有个自己的地址空间来调用一样,实际上它跟其他进程一样共享计算机的物理存储,如果系统运行的存储过低,它的地址空间甚至会被磁盘的交互区暂时寄用。存储管理的另外一个方面是防止一个进程访问其他进程的地址空间--对于多进程操作系统来说这是很必要的一个防范措施。

    Kernel同样还配置网络链接协议比如IP、TCP和UDP等,它们在网络上提供机器对机器(machine-to-machine)和进程对进程(process-to-process)的通信。这里又会造成一种假象,即TCP在两个进程之间提供了一个固定连接--就好像连接两个电话的铜线一样,实际中却并没有固定的连接,特殊的引用协议比如FTP、DNS和HTTP是通过用户级程序来实施的,而并非Kernel的一部分。

    Linux(像之前的Unix)在安全方面口碑很好,这是因为Kernel跟踪记录了每个运行进程的user ID和group ID,每次当一个应用企图访问资源(比如打开一个文件来写入)的时候,Kernel就会核对文件上的访问许可然后做出允许/禁止的命令。这种访问控制模式最终对整个Linux系统的安全作用很大。

    Kernel还提供了一大套模块的集合,其功能包括如何处理与硬件设备交流的诸多细节、如何从磁盘读取一个分区、如果从网络接口卡获取数据包等。有时我们称这些为设备驱动。
 

模块化的Kernel

    现在我们队Kernel是做什么的已经有了一些了解,让我们再来简单看下它的物理组成。早期版本的Linux Kernel是整体式的,也就是说所有的部件都静态地连接成一个(很大的)执行文件。

    相比较而言,现在的Linux Kernel是模块化的:许多功能包含在模块内,然后动态地载入kernel中。这使得kernel的内核很小,而且在运行kernel时可以不必reboot就能载入和替代模块。

    Kernel的内核在boot time时从位于/boot 目录的一个文件加载进存储中,通常这个/boot 目录会被叫做KERNELVERSION,KERNELVERSION与kernel版本有关。(如果你想知道你的kernel版本是什么,运行命令行显示系统信息-r。)kernel的模块位于目录/lib/modules/KERNELVERSION之下,所有的组件都会在kernel安装时被拷贝。
 

管理模块

    大部分情况下,Linux管理它的模块不需要你的帮忙,但是如果必要的时候有命令行可以来手动检查和管理模块。比如,为了查清楚当前到底哪个模块在载入kernel。这里有一个lsmod输出的例子:

    # lsmod

    pCSPkr                  4224   0

    hci_usb                  18204  2

    psmouse                38920  0

    bluetooth                55908  7  rfcomm,l2cap,hci_usb

    yenta_socket          27532  5

    rSRC_nonstatIC     14080  1  yenta_socket

    iSOFs                     36284  0

    输出的内容包括:模块的名字、大小、使用次数和依赖于它的模块列表。使用次数对防止卸载当前活跃的模块非常总要。Linux只允许使用次数为零的模块被移除。

    你可以使用modprobe来手动加载和卸载模块,(还有两个命令行叫做insmodrmmod,但modprobe更易于使用因为它自动移除了模块依赖)。比如lsmod的输出在我们的电脑上显示了一个名叫isofs的卸载模块,它的使用次数是零而且没有依赖模块,(isofs是一个模块,它支持CD上使用的ISO系统文件格式)这种情况下,kernel会允许我们卸载模块:

    # modprobe -r isofs 

    现在,isofs不再显示在Ismod的输出中,kernel由此节省了36,284字节的存储。如果你放入CD并且让它自动安装,kernel将自动重新载入isofs模块,而且isofs的使用次数增加到1次。如果这时候你还试图移除模块,就不会成功了因为它正在被使用:

    # modprobe -r isofs   

    FATAL: Module isofs is in use.

    Lsmod只是列出了当前被载入的模块,modprobe则将列出所有可用的模块,它实际上输出了/lib/modules/KERNELVERSION目录下所有的模块,名单会很长!

    实际上,使用modprobe来手动加载一个模块并不常见,但确实可以通过modprobe命令行来对模块设置参数,例如:

    # modprobe usbcore blinkenlights=1 

    我们并不是在创建blinkenlights,而是usbcore模块的实参数。

    那么如何知道一个模块会接受什么参数呢?一个比较好的方法是使用modinfo命令,它列出了关于模块的种种信息。这里有一个关于模块snd-hda-intel的例子

    # modinfo snd-hda-intel

    filename:      /lib/modules/2.6.20-16-generic/kernel/sound/PCI/hda/snd-hda-intel.ko

    description:   Intel HDA driver

    license:       GPL

    srcversion:    A3552B2DF3A932D88FFC00C

    alias:         pci:v000010DEd0000055Dsv*sd*bc*sc*i*

    alias:         pci:v000010DEd0000055Csv*sd*bc*sc*i*

    depends:       snd-PCM,snd-page-alLOC,snd-hda-codec,snd

    vermagic:      2.6.20-16-generic SMP mod_unload 586

    parm:          index:Index value for Intel HD audio interface. (int)

    parm:          id:ID string for Intel HD audio interface. (charp)

    parm:          model:Use the given board model. (charp)

    parm:          position_fix:Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size). (int)

    parm:          probe_mask:Bitmask to probe codecs (default = -1). (int)

    parm:          single_cmd:Use single command to communicate with codecs (for debugging only). (bool)

    parm:          enable_msi:Enable Message SignaLED Interrupt (MSI) (int)

    parm:          enable:bool

    对我们来说比较有兴趣的以"parm"开头的那些部分:显示了模块所接受的参数。这些描述都比较简明,如果想要更多的信息,那就安装kernel的源代码,在类似于/usr/src/KERNELVERSION/Documentation的目录下你会找到。

    里面会有一些有趣的东西,比如文件/usr/src/KERNELVERSION/Documentation/sound/alsa/ALSA-Configuration.txt描述的是被许多ALSA声音模块承认的参数;/usr/src/KERNELVERSION/Documentation/kernel-parameters.txt这个文件也很有用。

    前几天在Ubuntu论坛有一个例子,说的是如何将参数传递到一个模块(详见https://help.ubuntu.com/community/HdaIntelSoundHowto)。实际上问题的关键是snd-hda-intel参数在正确驱动声音硬件时需要一点操作,而且在boot time加载时会中止。解决方法的一部分是将probe_mask=1选项赋给模块,如果你是手动加载模块,你需要输入:

    # modprobe snd-hda-intel probe_mask=1 

    更有可能,你在文件/etc/modprobe.conf中放置这样类似的一行:options snd-hda-intel probe_mask=1

    这"告诉"modprobe每次在加载snd-hda-intel模块时包含probe_mask=1选项。现在的有些Linux版本将这一信息分离进/etc/modprobe.d下的不同文件中了,而不是放入modprobe.conf中。
 

/proc系统文件

    Linux kernel同样通过/proc系统文件来展示了许多细节。为了说明/proc,我们首先需要扩展我们对于文件的理解。除了认为文件就是存储在硬盘或者CD或者存储空间上的持久信息之外,我们还应当把它理解为任何可以通过传统系统调用如:打开、读、写、关闭等访问的信息,当然它也可以被常见的程序访问。

    /proc之下的"文件"完全是kernel虚拟的一个部分,给我们一个视角可以看到kernel内部的数据结构。实际上,许多Linux的报告工具均能够很好地呈现在/proc下的文件中寻到的格式化版本的信息。比如,一行/proc/modules将展示一行当前加载的模块。

    同样的,/proc/meminfo提供了关于虚拟存储系统当前状态的更多细节信息,而类如vmstat的工具则是以一种更加可理解的方式提供了相同的一些信息;/proc/net/arp显示了系统ARP cache的当前内容,从命令行来说,arp -a显示的也是相同的信息。

    尤其有意思的是/proc/sys下的"文件"。/proc/sys/net/ipv4/ip_forward下的设置告诉我们kernel是否将转发IP数据包,也就是说是否扮演网关的作用。现在,kernel告诉我们这是关闭的:

    # cat /proc/sys/net/ipv4/ip_forward   

    0

    当你发现你可以对这些文件写入的时候,你会觉得更加有意思。继续举例来说:

    # echo 1 > /proc/sys/net/ipv4/ip_forward

将在运行的kernel中打开IP 转发(IP forwarding)

除了使用cat和echo来检查和更正/proc/sys下的设置以外,你也可以使用sysctl命令:

    # sysctl net.ipv4.ip_forward     

    net.ipv4.ip_forward = 0 

这等同于:

    # cat /proc/sys/net/ipv4/ip_forward   

    0 

也等同于:

    # sysctl -w net.ipv4.ip_forward=1  

    net.ipv4.ip_forward = 1 

还等同于:

    # echo 1 > /proc/sys/net/ipv4/ip_forward 

    需要注意的是,以这种方式你所做的设置改变只能影响当前运行的kernel的,当reboot的时候就不再有效。如果想让设置永久有效,将它们放置在/etc/sysctl.conf文件中。在boot time时,sysctl将自动重新确定它在此文件下找到的任何设置。

/etc/sysctl.conf下的代码行大概是这样的:net.ipv4.ip_forward=1
 

性能调优(performance tuning)

    有这样一个说法:/proc/sys下可写入的参数孕育了整个Linux性能调优的亚文化。我个人觉得这种说法有点过夸,但这里会有几个你确实很想一试的例子:Oracle 10g的安装说明(www.oracle.com/technology/obe/obe10gdb/install/linuxpreinst/linuxpreinst.htm)要求你设置一组参数,包括:kernel.shmmax=2147483648 这将公用存储器的大小设置为2GB。(公用存储器是处理期内的通信机制,允许存储单元在多个进程的地址空间内同时可用)

    IBM 'Redpaper'在Linux性能和调优方面的说明(www.redbooks.ibm.com/abstracts/redp4285.html)在调教/proc/sys下的参数方面给出了不少建议,包括:vm.swappiness=100 这个参数控制着存储页如何被交换到磁盘。

    一些参数可以被设置从而提高安全性,如net.ipv4.icmp_echo_ignore_broadcasts=1 它"告诉"kernel不必响应ICMP请求,从而使得你的网络免受类如Smurf攻击之类的拒绝服务器(denial-of-service)型攻击。

    net.ipv4.conf.all.rp_filter=1 则是"告诉"kernel加强入站过滤(ingress filtering)和出站过滤(egress filtering)

    那么有没有一个说明能涵盖这所有的参数?好吧,这有一行命令:# sysctl -a 它将展示所有的参数名字和当前值。列表很长,但是你无法知道这些参数是做什么的。另外比较有用的参考是Red Hat Enterprise Linux Reference Guide,对此有整章节的描述,你可以从www.redhat.com/docs/manuals/enterprise上下载。

2014-04-09 16:21:11 layverns 阅读数 3195

u-boot启动参数

bootdelay=3                 //自动启动等待的秒数

baudrate=115200  //串口波特率

ethaddr=00:12:34:56:78:9a    //以太网卡MAC地址

ipaddr=192.168.0.9                   //本机IP地址       

serverip=192.168.0.1                //tftp服务器IP地址

gatewayip=192.168.1.2            //网关IP地址

netmask=255.255.255.0         //子网掩码

mtdids=nand0=s5pv210-nand  //存储设备ID

mtdparts=mtdparts=s5pv210-nand:1m@0(bios),1m(params),3m(logo),5m(kernel),-(root)  //存储设备分区表

bootcmd=tftp 50008000 zImage; bootm 50008000   //自启动的命令

//给内核传递的参数

bootargs=root=/dev/nfs nfsroot=192.168.1.8:/nfsroot ip=192.168.1.6:192.168.1.8:192.168.1.1:255.255.255.0::eth0:on init=/linuxrc console=ttySAC0,115200  

stdin=serial   //标准输入,一般为串口

stdout=serial

stderr=serial


Linux内核启动参数

(1)boot=”

此参数指明包含引导扇区的设备名(如:/dev/had),若此项忽略,则从当前的根分区中读取引导扇区。

(2)root=”

此参数告诉内核启动时以哪个设备作为根文件系统使用,其设定值为构造内核时根文件系统的设备名,可用的设备名有:

/dev/hdaN~/dev/hddN:ST-506兼容硬盘,a到d上的N个分区

/dev/sdaN~/dev/sdeN:SCSI兼容硬盘,a到e上的N个分区

/dev/nfs:由网络取得根文件系统的标志

(3)“nfsroot=”

若需通过NFS提供根文件系统来引导无盘工作站,此参数为内核指定了网络根文件系统所在的机程序、目录及NFS,其格式为:nfsroot=(〈server_ip〉:)〈root_dir)(,nfs_options〉)

(4)“nfsaddrs=”

设定网络通讯所需的各种网络界面地址,如无此参数,则内核会试图用反向地址解析协定(RARP)或启动协定(BOOTP)找出这些参数,其格式为:   nfsaddrs=〈客户端IP〉:〈服务端IP〉:〈网关IP〉:〈子网屏蔽〉:〈客户端名称〉:〈网络设备名 〉:〈auto〉

(5)“image=”

指定Linux的内核文件。

(6)“delay=”

设定引导第一个映像前的等待时间。

(7)“init=”

内核初始化时执行的程序,通常过程为init、getty、rc和sh,版本1.3.43以来的Linux内核能够执行/sbin/init说明的命令行,若在引导过程中出现问题,则可设

init=/bin/sh直接跳到Shell。设置内核执行的初始化进程名,如果该项没有设置,内核会按顺序尝试/etc/init,/bin/init,/sbin/init, /bin/sh,如果所有的都没找到,

内核会抛出 kernel panic:的错误。

(8)“mem=”

此参数的目的之一是为Linux指定使用的内存数量:如mem=96MB,目的之二是指定mem=nopentium告诉内核不要使用4MB分页表。

(9)“noinitrd”

(仅当内核配置了选项 CONFIG_BLK_DEV_RAM和CONFIG_BLK_DEV_INITRD)现在的内核都可以支持initrd了,引导进程首先装载内核和一个初始化的ramdisk,然后内核

initrd转换成普通的ramdisk,也就是读写模式的根文件系统设备。然后linuxrc执行,然后装载真正的根文件系统,之后ramdisk被卸载,最后执行启动序列,比如/sbin/init。

选项noinitrd告诉内核不执行上面的步骤,即使内核编译了initrd,而是把initrd的数据写到 /dev/initrd,只是这是一个一次性的设备。

2018-08-04 11:31:28 zhangcanyan 阅读数 2439

这3部分是怎么相互协作来构成这个系统的呢?

各自有什么用呢?

三者有什么联系?

怎么联系?

系统的执行流程又是怎么样的呢?

搞清楚这个问题你对整个系统的运行就很清楚了,对于下一步制作这个linux系统就打下了另一个重要的根基。


下面是笔者针对网上bootloader、linuxkernel(linux内核)、rootfile(根文件系统),三者关系的一个总结

 

1.LINUX中bootloader、linuxkernel、rootfile三者之间的确切关系是怎么样的呢?

 

bootloader->linuxkernel->rootfile

启动顺序。

后者需要前者提供功能支持,前者的目的就是启动后者。

 

2、嵌入式linux的bootloader的启动流程是怎样的

 

一个嵌入式Linux系统从软件角度看可以分为四个部分:引导加载程序(Bootloader),Linux内核,文件系统,应用程序。

当系统首次引导时,或系统被重置时,处理器会执行一个位于Flash/ROM中的已知位置处的代码,Bootloader就是这第一段代码。它主要用来初始化处理器及外设,然后调用Linux内核。Linux内核在完成系统的初始化之后需要挂载某个文件系统作为根文件系统(RootFilesystem),然后加载必要的内核模块,启动应用程序。这就是嵌入式Linux系统启动过程Linux引导的整个过程。

 

根文件系统是Linux系统的核心组成部分,它可以作为Linux系统中文件和数据的存储区域,通常它还包括系统配置文件和运行应用软件所需要的库。应用程序可以说是嵌入式系统的“灵魂”,它所实现的功能通常就是设计该嵌入式系统所要达到的目标。如果没有应用程序的支持,任何硬件上设计精良的嵌入式系统都没有实用意义。

从以上分析可以看出Bootloader在运行过程中虽然具有初始化系统和执行用户输入的命令等作用,但它最根本的功能就是为了启动Linux内核,让我们进一步分析Bootloader和Linux内核在嵌入式系统中的关系和作用。

 

Bootloader

1、Bootloader基本概述

Bootloader是嵌入式系统的引导加载程序,它是系统上电后运行的第一段程序,其作用类似于PC机上的BIOS。Bootloader是依赖于硬件而实现的,特别是在嵌入式领域,为嵌入式系统建立一个通用的Bootloader是很困难的,但为了能达到启动Linux内核的目的,所有的Bootloader都必须具备以下功能:

1)初始化RAM

因为Linux内核一般都会在RAM中运行,所以在调用Linux内核之前Bootloader必须设置和初始化RAM,为调用Linux内核做好准备。初始化RAM的任务包括设置CPU的控制寄存器参数,以便能正常使用RAM以及检测RAM大小等。

2)初始化串口端口

在Linux的启动过程中有着非常重要的作用,它是Linux内核和用户交互的方式之一。Linux在启动过程中可以将信息通过串口输出,这样便可清楚的了解Linux的启动过程。虽然它并不是Bootloader必须要完成的工作,但是通过串口输出信息是调试Bootloader和Linux内核的强有力的工具,所以一般的Bootloader都会在执行过程中初始化一个串口作为调试端口。

3)检测处理器类型

Bootloader在调用Linux内核前必须检测系统的处理器类型,并将其保存到某个常量中提供给Linux内核。Linux内核在启动过程中会根据该处理器类型调用相应的初始化程序。

4)设置Linux启动参数

Bootloader在执行过程中必须设置和初始化Linux的内核启动参数。

5)调用Linux内核映像

Bootloader完成的最后一项工作便是调用Linux内核。如果Linux内核存放在Flash中,并且可直接在上面运行(这里的Flash指NorFlash),那么可直接跳转到内核中去执行。但由于在Flash中执行代码会有种种限制,而且速度也远不及RAM快,所以一般的嵌入式系统都是将Linux内核拷贝到RAM中,然后跳转到RAM中去执行。

 

2、Bootloader启动过程

嵌入式Linux系统通过Bootloader引导,一上电,就要执行Bootloader来初始化系统。在完成对系统的初始化任务之后,它会将非易失性存储器(通常是Flash或DOC等)中的Linux内核拷贝到RAM中去,然后跳转到内核的第一条指令处继续执行,从而启动Linux内核。Bootloader和Linux内核有着密不可分的联系。

Bootloader多数有两个阶段的启动过程:

Stage1:

基本的硬件初始化

为加载stage2准备RAM空间

拷贝内核映像和文件系统映像到RAM中

设置堆栈指针sp

跳到stage2的入口点

Stage2:

初始化本阶段要使用到的硬件设备

检测系统的内存映射

加载内核映像和文件系统映像

设置内核的启动参数

嵌入式系统中广泛采用的非易失性存储器通常是Flash,而Bootloader就位于该存储器的最前端,所以系统上电或复位后执行的第一段程序便是Bootloader。Bootloader在flash中的存储示意图如下:

Bootloader启动流程图

 

3、Bootloader的启动方式

3.1网络启动方式

这种方式的开发板不需要较大的存储介质,跟无盘工作站有点类似,但是使用这种启动方式之前,需要把Bootloader安装到板上的EPROM或者Flash中。Bootloader通过以太网接口远程下载Linux内核映像或者文件系统。Bootloader下载文件一般都使用TFTP网络协议,还可以通过DHCP的方式动态配置IP地址。

3.2硬盘启动方式

传统的Linux系统运行在台式机或者服务器上,这些计算机一般都使用BIOS引导,并使用磁盘作为存储介质。Linux传统上是LILO(LinuxLoader)引导,后来又出现了GUN的软件(GrandUnifiedBootloader)。这两种Bootloader广泛应用在X86的Linux系统上。

3.3Flash启动方式

大多数嵌入式系统上都使用Flash存储介质。Flash有很多类型,包括NORFlash、NANDFlash和其它半导体盘。它们之间的不同在于:NORFlash支持芯片内执行(XIP,eXecuteInPlace),这样代码可以在Flash上直接执行而不必拷贝到RAM中去执行。而NANDFlash并不支持XIP,所以要想执行NANDFlash上的代码,必须先将其拷贝到RAM中去,然后跳到RAM中去执行。NORFlash使用最为普遍。Bootloader一般放在Flash的底端或者顶端,这需要根据处理器的复位向量来进行设置。可以配置成MTD设备来访问Flash分区

 

3.linux的内核是由bootloader装载到内存中的?

 

提问:

 

参考书上写的内容bootloader的作用是加载内核并将控制权转交给内核程序,但是内核文件本身是存放在硬盘的文件系统中,bootloader只有512B,此时并没有能力识别文件系统和initrd,因此是如何在硬盘上定位内核文件的?

 

对于文件系统的一个疑问,以linux中的ext文件系统为例,文件是由超级块,inode,数据块组成的,要读取数据必须找到inode,从中取出文件是有哪些bloc块组成的,但是是谁记录inode的位置呢?是否跟硬盘的MBR一个原理?存在硬盘分区的前几个固定位置,然后调用系统中断来取?

 

回答:

 

linux的内核的确是由bootloader装载到内存中的。linux的bootloader有2个部分组成:bootstrap和uboot。所以更准确点的说法是:linux的内核是由uboot装载到内存中的。内核文件本身是存放在硬盘的文件系统中,这句话就是错的。内核和文件系统是分开存储的。uboot读取kernel到内存是从kernel开始存储的地址开始读取的,而读取开始位置和读取大小,是由环境变量决定的。所以这个时候不需要文件系统的。

 

给你张图片,便于理解吧。这张图片是bootstrap、uboot、环境变量、kernel、文件系统在nandflash里面的存储分布。

 

 

其中rootfs.jfss2就是文件系统。

 

4.请问bootloader、u-boot和linux内核的区别和关系是怎样的?麻烦哪位大侠给小弟指导指导

 

bootloader是取代mbr功能的,可以看成mbr的加强.u-boot是把usb盘做成启动盘的,linux内核就是linux系统的核心,你用的linux就是在内核基础上扩展了shell和应用程序.

 

mbr=masterbootrecord,主引导记录,位置在磁盘的0磁道0柱面1扇区。bios启动会首先访问他,把启动交给mbr,mbr记录从哪个地方开始启动。

 

简介

 

MBR,全称为MasterBootRecord,即硬盘的主引导记录。

 

为了便于理解,一般将MBR分为广义和狭义两种:广义的MBR包含整个扇区(引导程序、分区表及分隔标识),也就是上面所说的主引导记录;而狭义的MBR仅指引导程序而言。

 

硬盘的0柱面、0磁头、1扇区称为主引导扇区(也叫主引导记录MBR)。它由三个部分组成,主引导程序、硬盘分区表DPT(DiskPartitiontable)和硬盘有效标志(55AA)。在总共512字节的主引导扇区里主引导程序(bootloader)占446个字节,第二部分是Partitiontable区(分区表),即DPT,占64个字节,硬盘中分区有多少以及每一分区的大小都记在其中。第三部分是magicnumber,占2个字节,固定为55AA。

 

5.为什么bootloader要去Flash上读入Linux内核

 

你这个问题应该分为几个部分

1bootloader主要是负责系统初始化和系统加载的嵌入式系统一般会把bootloader和系统内核分开存放,这样的话系统内核损坏了的话还可以通过bootloader进行恢复

2linux内核一般比bootloader大很多。一个嵌入式系统,在系统刚通电的时候,根据cpu的不同,他们是从一个固定的内存地址开始运行的。一般情况下,这个固定地址会是一个ROM,其存储空间一般较小,一般用来存放bootloader。而根据板子设计的不同,系统内核是保持在flash或者其他存储介质上的。

3bootloader在完成硬件初始化后,从存储介质上把系统内核读入到指定的内存区域,然后用一个跳转指令跳转到系统内核处开始执行。注意,这个存储介质不一定是flash

 

 

6.为什么需要BootLoader?linux

 

引导加载程序是系统加电后运行的第一段软件代码。PC机中的引导加载程序由BIOS(其本质就是一段固件程序)和位于硬盘MBR中的OSBootLoader(比如,LILO和GRUB等)一起组成。BIOS在完成硬件检测和资源分配后,将硬盘MBR中的BootLoader读到系统的RAM中,然后将控制权交给OSBootLoader。BootLoader的主要运行任务就是将内核映象从硬盘上读到RAM中,然后跳转到内核的入口点去运行,也即开始启动操作系统。

而在嵌入式系统中,通常并没有像BIOS那样的固件程序(注,有的嵌入式CPU也会内嵌一段短小的启动程序),因此整个系统的加载启动任务就完全由BootLoader来完成。比如在一个基于ARM7TDMIcore的嵌入式系统中,系统在上电或复位时通常都从地址0x00000000处开始执行,而在这个地址处安排的通常就是系统的BootLoader程序。

简单地说,BootLoader就是在操作系统内核运行之前运行的一段小程序。通过这段小程序,我们可以初始化硬件设备、建立内存空间的映射图,从而将系统的软硬件环境带到一个合适的状态,以便为最终调用操作系统内核准备好正确的环境。

通常,BootLoader是严重地依赖于硬件而实现的,特别是在嵌入式世界。因此,在嵌入式世界里建立一个通用的BootLoader几乎是不可能的。尽管如此,我们仍然可以对BootLoader归纳出一些通用的概念来,以指导用户特定的BootLoader设计与实现。

在专用的嵌入式板子运行GNU/Linux系统已经变得越来越流行。一个嵌入式Linux系统从软件的角度看通常可以分为四个层次:

1、引导加载程序。包括固化在固件(firmware)中的boot代码(可选),和BootLoader两大部分。

2、Linux内核。特定于嵌入式板子的定制内核以及内核的启动参数。

3、文件系统。包括根文件系统和建立于Flash内存设备之上文件系统。通常用ramdisk来作为rootfs。

4、用户应用程序。特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式GUI有:MicroWindows和MiniGUI等。

2014-11-15 09:43:30 skyflying2012 阅读数 35086
利用工作之便,今天研究了kernel下cmdline参数解析过程,记录在此,与大家共享,转载请注明出处,谢谢。


Kernel 版本号:3.4.55

Kernel启动时会解析cmdline,然后根据这些参数如console root来进行配置运行。


Cmdline是由bootloader传给kernel,如uboot,将需要传给kernel的参数做成一个tags链表放在ram中,将首地址传给kernel,kernel解析tags来获取cmdline等信息。

Uboot传参给kernel以及kernel如何解析tags可以看我的另一篇博文,链接如下:

http://blog.csdn.net/skyflying2012/article/details/35787971


今天要分析的是kernel在获取到cmdline之后如何对cmdline进行解析。
依据我的思路(时间顺序,如何开始,如何结束),首先看kernel下2种参数的注册。
第一种是kernel通用参数,如console=ttyS0,115200  root=/rdinit/init等。这里以console为例。

第二种是kernel下各个driver中需要的参数,在写driver中,如果需要一些启动时可变参数。可以在driver最后加入module_param()来注册一个参数,kernel启动时由cmdline指定该参数的值。

这里以drivers/usb/gadget/serial.c中的use_acm参数为例(这个例子有点偏。。因为最近在调试usb虚拟串口)


一 kernel通用参数

对于这类通用参数,kernel留出单独一块data段,叫.ini.setup段。在arch/arm/kernel/vmlinux.lds中:

.init.data : {
  *(.init.data) *(.cpuinit.data) *(.meminit.data) *(.init.rodata) *(.cpuinit.rodata) *(.meminit.rodata) . = ALIGN(32); __dtb_star
 . = ALIGN(16); __setup_start = .; *(.init.setup) __setup_end = .;
  __initcall_start = .; *(.initcallearly.init) __initcall0_start = .; *(.initcall0.init) *(.initcall0s.init) __initcall1_start =
  __con_initcall_start = .; *(.con_initcall.init) __con_initcall_end = .;
  __security_initcall_start = .; *(.security_initcall.init) __security_initcall_end = .;
  . = ALIGN(4); __initramfs_start = .; *(.init.ramfs) . = ALIGN(8); *(.init.ramfs.info)
 }

可以看到init.setup段起始__setup_start和结束__setup_end

.init.setup段中存放的就是kernel通用参数和对应处理函数的映射表。在include/linux/init.h

struct obs_kernel_param {
    const char *str;
    int (*setup_func)(char *);
    int early;
};

/*
 * Only for really core code.  See moduleparam.h for the normal way.
 *
 * Force the alignment so the compiler doesn't space elements of the
 * obs_kernel_param "array" too far apart in .init.setup.
 */
#define __setup_param(str, unique_id, fn, early)            \
    static const char __setup_str_##unique_id[] __initconst \
        __aligned(1) = str; \
    static struct obs_kernel_param __setup_##unique_id  \
        __used __section(.init.setup)           \
        __attribute__((aligned((sizeof(long)))))    \
        = { __setup_str_##unique_id, fn, early }

#define __setup(str, fn)                    \
    __setup_param(str, fn, fn, 0)
/* NOTE: fn is as per module_param, not __setup!  Emits warning if fn
 * returns non-zero. */
#define early_param(str, fn)                    \
    __setup_param(str, fn, fn, 1)

可以看出宏定义__setup以及early_param定义了obs_kernel_param结构体,该结构体存放参数和对应处理函数,存放在.init.setup段中。

可以想象,如果多个文件中调用该宏定义,在链接时就会根据链接顺序将定义的obs_kernel_param放到.init.setup段中。

console为例,在/kernel/printk.c中,如下:

static int __init console_setup(char *str)
{
.......
}
__setup("console=", console_setup);

__setup宏定义展开,如下:

Static struct obs_kernel_param __setup_console_setup 
__used_section(.init.setup) __attribute__((aligned((sizeof(long)))) = {
.name = “console=”,
.setup_func = console_setup,
.early = 0
}

__setup_console_setup编译时就会链接到.init.setup段中,kernel运行时就会根据cmdline中的参数名与.init.setup段中obs_kernel_paramname对比。

匹配则调用console-setup来解析该参数,console_setup的参数就是cmdlineconsole的值,这是后面参数解析的大体过程了。

 

二 driver自定义参数

对于driver自定义参数,kernel留出rodata段一部分,叫__param,在arch/arm/kernel/vmlinux.lds中,如下:

__param : AT(ADDR(__param) - 0) { __start___param = .; *(__param) __stop___param = .; }

该段放在.rodata段中。

那该段中存放的是什么样的数据呢?

Driver中使用module_param来注册参数,跟踪这个宏定义,最终就会找到对__param段的操作函数如下:

/* This is the fundamental function for registering boot/module
   parameters. */
#define __module_param_call(prefix, name, ops, arg, perm, level)    \
    /* Default value instead of permissions? */         \
    static int __param_perm_check_##name __attribute__((unused)) =  \
    BUILD_BUG_ON_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2))  \
    + BUILD_BUG_ON_ZERO(sizeof(""prefix) > MAX_PARAM_PREFIX_LEN);   \
    static const char __param_str_##name[] = prefix #name;      \
    static struct kernel_param __moduleparam_const __param_##name   \
    __used                              \
    __attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void *)))) \
    = { __param_str_##name, ops, perm, level, { arg } }
........
#define module_param(name, type, perm)              \
    module_param_named(name, name, type, perm)

#define module_param_named(name, value, type, perm)            \
    param_check_##type(name, &(value));                \
    module_param_cb(name, ¶m_ops_##type, &value, perm);        \
    __MODULE_PARM_TYPE(name, #type)

#define module_param_cb(name, ops, arg, perm)                     \
    __module_param_call(MODULE_PARAM_PREFIX, name, ops, arg, perm, -1)

driver/usb/gadget/serial.c中的use_acm为例,如下:

static bool use_acm = true;
module_param(use_acm, bool, 0);

Module_param展开到__module_param_call,如下:

Static bool use_acm = true;
Param_check_bool(use_acm, &(use_acm));
__module_param_call(MODULE_PARAM_PREFIX, use_acm, ¶m_ops_bool, &(use_acm, 0, -1));
__MODULE_PARAM_TYPE(use_acm, bool);

__module_param_call展开,可以看到是定义了结构体kernel_param,如下:

Static struct kernel_param __moduleparam_const __param_use_acm 
 __used   __attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void *)))) = {
.name = MODULE_PARAM_PREFIX#use_acm,
.ops = ¶m_ops_bool,
.Perm=0,
.level = -1.
.arg = &use_acm
}

很清楚,跟.init.setup段一样,kernel链接时会根据链接顺序将定义的kernel_param放在__param段中。

Kernel_param3个成员变量需要注意:

(1)

ops=param_ops_bool,是kernel_param_ops结构体,定义如下:

struct kernel_param_ops param_ops_bool = {
    .set = param_set_bool,
    .get = param_get_bool,
};

2个成员函数分别去设置和获取参数值

kernel/param.c中可以看到kernel默认支持的driver参数类型有bool byte short ushort int uint long ulong string(字符串) charp(字符串指针)array等。

对于默认支持的参数类型,param.c中提供了kernel_param_ops来处理相应类型的参数。

2

Arg = &use_acm,宏定义展开,可以看到arg中存放use_acm的地址。参数设置函数param_set_boolconst char *val, const struct kernel_param *kp

val值设置到kp->arg地址上,也就是改变了use_acm的值,从而到达传递参数的目的。

(3)

.name=MODULE_PARAM_PREFIX#use_acm,定义了该kernel_paramname

MODULE_PARAM_PREFIX非常重要,定义在include/linux/moduleparam.h中:

* You can override this manually, but generally this should match the
   module name. */
#ifdef MODULE
#define MODULE_PARAM_PREFIX /* empty */
#else
#define MODULE_PARAM_PREFIX KBUILD_MODNAME "."
#endif

如果我们是模块编译(make modules),则MODULE_PARAM_PREFIXempty

在模块传参时,参数名为use_acm,如insmod g_serial.ko use_acm=0

正常编译kernelMODULE_PARAM_PREFIX为模块名+”.”

如果我们在传参时不知道自己的模块名是什么,可以在自己的驱动中加打印,将MODULE_PARAM_PREFIX打印出来,来确定自己驱动的模块名。

所以这里将serial.c编入kernel,根据driver/usb/gadget/Makefile,如下:

g_serial-y          := serial.o
....
obj-$(CONFIG_USB_G_SERIAL)  += g_serial.o

最终是生成g_serial.o,模块名为g_serial.ko.name = g_serial.use_acm

kernel传参时,该参数名为g_serial.use_acm

这样处理防止kernel下众多driver中出现重名的参数。

 

可以看出,对于module_param注册的参数,如果是kernel默认支持类型,kernel会提供参数处理函数。

如果不是kernel支持参数类型,则需要自己去实现param_ops##type了。

这个可以看drivers/video/uvesafb.c中的scroll参数的注册(又有点偏。。。无意间找到的)。

 

参数注册是在kernel编译链接时完成的(链接器将定义结构体放到.init.setup__param中)

接下来需要分析kernel启动时如何对传入的cmdline进行分析。


三 kernel对cmdline的解析

根据我之前写的博文可知,start_kernelsetup_arch中解析tags获取cmdline,拷贝到boot_command_line中。我们接着往下看start_kernel

调用setup_command_line,将cmdline拷贝2份,放在saved_command_line static_command_line

下面调用parse_early_param(),如下:

void __init parse_early_options(char *cmdline)
{
    parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param);
}

/* Arch code calls this early on, or if not, just before other parsing. */
void __init parse_early_param(void)
{
    static __initdata int done = 0;
    static __initdata char tmp_cmdline[COMMAND_LINE_SIZE];

    if (done)
        return;

    /* All fall through to do_early_param. */
    strlcpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
    parse_early_options(tmp_cmdline);
    done = 1;
}
Parse_early_param拷贝cmdline到tmp_cmdline中一份,最终调用parse_args,如下:

/* Args looks like "foo=bar,bar2 baz=fuz wiz". */
int parse_args(const char *name,
           char *args,
           const struct kernel_param *params,
           unsigned num,
           s16 min_level,
           s16 max_level,
           int (*unknown)(char *param, char *val))
{
    char *param, *val;

    pr_debug("Parsing ARGS: %s\n", args);

    /* Chew leading spaces */
    args = skip_spaces(args);

    while (*args) {
        int ret;
        int irq_was_disabled;

        args = next_arg(args, ¶m, &val);
        irq_was_disabled = irqs_disabled();
        ret = parse_one(param, val, params, num,
                min_level, max_level, unknown);
        if (irq_was_disabled && !irqs_disabled()) {
            printk(KERN_WARNING "parse_args(): option '%s' enabled "
                    "irq's!\n", param);
        }
        switch (ret) {
        case -ENOENT:
            printk(KERN_ERR "%s: Unknown parameter `%s'\n",
                   name, param);
            return ret;
        case -ENOSPC:
            printk(KERN_ERR
                   "%s: `%s' too large for parameter `%s'\n",
                   name, val ?: "", param);
            return ret;
        case 0:
            break;
        default:
            printk(KERN_ERR
                   "%s: `%s' invalid for parameter `%s'\n",
                   name, val ?: "", param);
            return ret;
        }
    }

    /* All parsed OK. */
    return 0;
}
.....
void __init parse_early_options(char *cmdline)
{
    parse_args("early options", cmdline, NULL, 0, 0, 0, do_early_param);
}

Parse_args遍历cmdline,按照空格切割获取参数,对所有参数调用next_arg获取参数名param和参数值val。如console=ttyS0,115200,则param=consoleval=ttyS0,115200。调用parse_one。如下:

static int parse_one(char *param,
             char *val,
             const struct kernel_param *params,
             unsigned num_params,
             s16 min_level,
             s16 max_level,
             int (*handle_unknown)(char *param, char *val))
{
    unsigned int i;
    int err;

    /* Find parameter */
    for (i = 0; i < num_params; i++) {
        if (parameq(param, params[i].name)) {
            if (params[i].level < min_level
                || params[i].level > max_level)
                return 0;
            /* No one handled NULL, so do it here. */
            if (!val && params[i].ops->set != param_set_bool
                && params[i].ops->set != param_set_bint)
                return -EINVAL;
            pr_debug("They are equal!  Calling %p\n",
                   params[i].ops->set);
            mutex_lock(¶m_lock);
            err = params[i].ops->set(val, ¶ms[i]);
            mutex_unlock(¶m_lock);
            return err;
        }
    }

    if (handle_unknown) {
        pr_debug("Unknown argument: calling %p\n", handle_unknown);
        return handle_unknown(param, val);
    }

    pr_debug("Unknown argument `%s'\n", param);
    return -ENOENT;
}

由于从parse_early_options传入的num_params=0,所以parse_one是直接走的最后handle_unknown函数。该函数是由parse-early_options传入的do_early_param。如下:

static int __init do_early_param(char *param, char *val)
{
    const struct obs_kernel_param *p;

    for (p = __setup_start; p < __setup_end; p++) {
        if ((p->early && parameq(param, p->str)) ||
            (strcmp(param, "console") == 0 &&
             strcmp(p->str, "earlycon") == 0)
        ) {
            if (p->setup_func(val) != 0)
                printk(KERN_WARNING
                       "Malformed early option '%s'\n", param);
        }
    }
    /* We accept everything at this stage. */
    return 0;
}

Do_early_param遍历.init.setup段,如果有obs_kernel_paramearly1,或cmdline中有console参数并且obs_kernel_paramearlycon参数,则会调用该obs_kernel_paramsetup函数来解析参数。

Do_early_param会对cmdline中优先级较高的参数进行解析。我翻了下kernel源码找到一个例子,就是arch/arm/kernel/early_printk.c,利用cmdline参数earlyprintk来注册最早的一个console,有兴趣大家可以参考下。

如果想kernel启动中尽早打印输出,方便调试,可以注册strearlyconobs_kernel_param

在其setup参数处理函数中register_console,注册一个早期的console,从而是printk信息正常打印,这个在后面我还会总结一篇kernel打印机制来说这个问题。

do_early_param是为kernel中需要尽早配置的功能(如earlyprintk  earlycon)做cmdline的解析。

Do_early_param就说道这里,该函数并没有处理我们经常使用的kernel通用参数和driver自定义参数。接着往下看。代码如下:

    setup_arch(&command_line);
    mm_init_owner(&init_mm, &init_task);
    mm_init_cpumask(&init_mm);
    setup_command_line(command_line);
    setup_nr_cpu_ids();
    setup_per_cpu_areas();
    smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */

    build_all_zonelists(NULL);
    page_alloc_init();

    printk(KERN_NOTICE "Kernel command line: %s\n", boot_command_line);
    parse_early_param();
    parse_args("Booting kernel", static_command_line, __start___param,
           __stop___param - __start___param,
           -1, -1, &unknown_bootoption);

Parse_early_param结束后,start_kernel调用了parse_args。这次调用,不像parse_early_param中调用parse_args那样kernel_param指针都为NULL,而是指定了.__param段。

回到上面看parse_args函数,params参数为.__param段起始地址,numkernel_param个数。

Min_level,max_level都为-1.unknown=unknown_bootoption

Parse_args还是像之前那样,遍历cmdline,分割获取每个参数的paramval,对每个参数调用parse_one

回看Parse_one函数源码:

1parse_one首先会遍历.__param段中所有kernel_param,将其name与参数的param对比,同名则调用该kernel_param成员变量kernel_param_opsset方法来设置参数值。

联想前面讲driver自定义参数例子use_acm,cmdline中有参数g_serial.use_acm=0,则在parse_one中遍历匹配在serial.c中注册的__param_use_acm,调用param_ops_boolset函数,从而设置use_acm=0.

(2)如果parse_args传给parse_onekernel通用参数,如console=ttyS0,115200。则parse_one前面遍历.__param段不会找到匹配的kernel_param。就走到后面调用handle_unknown。就是parse_args传来的unknown_bootoption,代码如下: 

/*
 * Unknown boot options get handed to init, unless they look like
 * unused parameters (modprobe will find them in /proc/cmdline).
 */
static int __init unknown_bootoption(char *param, char *val)
{
    repair_env_string(param, val);

    /* Handle obsolete-style parameters */
    if (obsolete_checksetup(param))
        return 0;

    /* Unused module parameter. */
    if (strchr(param, '.') && (!val || strchr(param, '.') < val))
        return 0;

    if (panic_later)
        return 0;

    if (val) {
        /* Environment option */
        unsigned int i;
        for (i = 0; envp_init[i]; i++) {
            if (i == MAX_INIT_ENVS) {
                panic_later = "Too many boot env vars at `%s'";
                panic_param = param;
            }
            if (!strncmp(param, envp_init[i], val - param))
                break;
        }
        envp_init[i] = param;
    } else {</span>
<span style="font-size:14px;">        /* Command line option */
        unsigned int i;
        for (i = 0; argv_init[i]; i++) {
            if (i == MAX_INIT_ARGS) {
                panic_later = "Too many boot init vars at `%s'";
                panic_param = param;
            }
        }
        argv_init[i] = param;
    }
    return 0;
}

首先repair_env_string会将param val重新组合为param=val形式。

Obsolete_checksetup则遍历-init_setup段所有obs_kernel_param,如有param->strparam匹配,则调用param_>setup进行参数值配置。

这里需要注意的一点是repair_env_stringparam重新拼成了param=val形式。后面遍历匹配都是匹配的”param=”而不是“param”

如之前分析kernel通用参数所举例子,__setup(“console=”, console_setup)

Console=ttyS0115200,obsolete_checksetup是匹配前面console=,如果匹配,则跳过console=,获取到其值ttyS0,115200,调用其具体的setup函数来解析设置参数值。

可以想象,parse_one对于parse_args传来的每一个cmdline参数都会将.__param以及-init.setup段遍历匹配,匹配到strname一致,则调用其相应的setsetup函数进行参数值解析或设置。

Start_kernelParse_args结束,kernelcmdline就解析完成!

 

总结下kernel的参数解析:

1kernel编译链接,利用.__param .init.setup段将kernel所需参数(driver及通用)和对应处理函数的映射表(obs_kernel_param  kernel_param结构体)存放起来。

2Kernel启动,do_early_param处理kernel早期使用的参数(如earlyprintk earlycon

(3)parse_argscmdline每个参数都遍历__param .init.setup进行匹配,匹配成功,则调用对应处理函数进行参数值的解析和设置。


还有一点很值得思考,kernel下对于这种映射处理函数表方式还有很多使用。比如之前博文中uboot传参给kernel,kernel对于不同tags的处理函数也是以该种方式来映射的。

kernel下driver私有结构体的回调处理函数也有这个思想哇!










2012-12-26 17:26:38 muojie 阅读数 696

转自:http://smilejay.com/2011/10/kernel_parameters/

在Linux中,给kernel传递参数以控制其行为总共有三种方法:

1.build kernel之时的各个configuration选项。

2.当kernel启动之时,可以参数在kernel被GRUB或LILO等启动程序调用之时传递给kernel。

3.在kernel运行时,修改/proc或/sys目录下的文件。

这里我简单讲的就是第二种方式了,kernel在grub中配置的启动参数。

首先,kernel有哪些参数呢? 在linux的源代码中,有这样的一个文档Documentation/kernel-parameters.txt,它介绍了kernel的各个参数及其意义。

其次,kernel启动参数以空格分隔,而且是严格区分大小写的(如:mem和MEM是不一样的)。

再次,对于module特有的kernel参数写法是这样的,[module name].[parameter=XX],例如,igb.max_vfs=7这个kernel启动参数的效果就是相当于这样来动态加载module: modprobe igb max_vfs=7

另外,kernel是怎样处理这些启动参数的呢? 启动参数通常是这样的形式: name[=value_1][,value_2]…[,value_10]

“name”是关键字,内核用它来识别应该把”关键字”后面的值传递给谁,也就是如何处理这个值,是传递给处理进程还是作为环境变量或者抛给”init”。值的个数限制为10,你可以通过再次使用该关键字使用超过10个的参数。 首先,kernel检查关键字是不是 ‘root=’, ‘nfsroot=’, ‘nfsaddrs=’, ‘ro’, ‘rw’, ‘debug’或’init’,然后内核在bootsetups数组里搜索于该关键字相关联的已注册的处理函数,如果找到相关的已注册的处理函数,则调用这些函数并把关键字后面的值作为参数传递给这些函数。比如,你在启动时设置参数name=a,b,c,d,内核搜索bootsetups数组,如果发现”name”已注册,则调用”name”的设置函数如name_setup(),并把a,b,c,d传递给name_setup()执行。 所有型如”name=value”参数,如果没有被上面所述的设置函数接收,将被解释为系统启动后的环境变量,比如”TERM=vt100″启动参数就会被作为一个启动后的环境变量。所有没有被内核设置函数接收也没又被设置成环境变量的参数都将留给init进程处理,比如”single”。

下面简单总结一下我在工作中常用到的一些kernel启动参数吧。

根磁盘相关启动参数:

root #指出启动的根文件系统 如:root=/dev/sda1

ro #指定根设备在启动过程中为read-only,默认情况下一般都是这样配的

rw #和ro类似,它是规定为read-write,可写

rootfstype #根文件系统类型,如:rootfstype=ext4

Console和kernel log相关启动参数:

console #console的设备和选项,如:console=tty0 console=ttyS0

debug #enable kernel debugging 启动中的所有debug信息都会打印到console上

quiet #disable all log messages 将kernel log level设置为KERN_WARNING,在启动中只非常严重的信息

loglevel #设置默认的console日志级别,如:loglevel=7 (0~7的数字分别为:KERN_EMERG,..,KERN_DEBUG)

time #设置在每条kernel log信息前加一个时间戳

内存相关的启动参数:

mem #指定kernel使用的内存量,mem=n[KMG]

hugepages #设置大页表页(4MB大小)的最多个数,hugepages=n

CPU相关的启动参数:

mce # Enable the machine check exception feature.

nosmp #Run as a single-processor machine. 不使用SMP(多处理器)

max_cpus #max_cpus=n, SMP系统最多能使用的CPU个数(即使系统中有大于n个的CPU)

Ramdisk相关的启动参数:

initrd #指定初始化ramdisk的位置,initrd=filename

noinitrd #不使用initrd的配置,即使配置了initrd参数

初始化相关启动参数:

init #在启动时去执行的程序,init=filename,默认值为/sbin/init

PCI相关的启动参数:

pci #pci相关的选项,我常使用pci=assign_buses,也使用过pci=nomsi

SELinux相关启动参数:

enforcing #SELinux enforcing状态的开关,enforcing=0表示仅仅是记录危险而不是阻止访问,enforcing=1完全enable,默认值是0

selinux #在启动时关闭或开启SELinux,selinux=0表示关闭,selinux=1表示开启selinux

另外,还是用max_loop来指定最多可使用的回路设备。

在Redhat的系统中,还有个经常看到的kernel启动参数——rhgb,rhgb表示redhat graphics boot,就是会看到图片来代替启动过程中显示的文本信息,这些信息在启动后用dmesg也可以看到
rhgb = redhat graphical boot – This is a GUI mode booting screen with most of the information hidden while the user sees a rotating activity icon spining and brief information as to what the computer is doing.

quiet = hides the majority of boot messages before rhgb starts. These are supposed to make the common user more comfortable. They get alarmed about seeing the kernel and initializing messages, so they hide them for their comfort.

参考资料:

linux kernel documents

《Linux kernel in a nutshell》

linux kernel启动流程

阅读数 3002