今天在考虑如何尽快启动一个应用程序，播个开机音乐什么的。
最开始的启动流程是这样的，bootloader 启动kernel，kernel跑完挂载文件系统，
然后会执行/init，而这个init 是指向busybox的一个软链接，
busybox做一些事情后，会解析/etc/inittab , 其中调用/etc/init.d/rcS 脚本，
rcS脚本里面再调用其他脚本，做一些开网络之类的功能，全部做完大概五秒多，打印出了“/ #”
此处简化下，暂且认为rcS脚本是这样的吧
#!/bin/sh
/etc/init.d/zqbNetwork start
这个应用程序呢，暂且叫做 zqbMusic 吧，是用来放音乐的，此处想放点开机提示音，所以我们有个音乐文件，叫kaiji.wav
调用一下 ./zqbMusic kaiji.wav 就播放了。大概一秒的音乐。
那么问题就是，如何尽快播放这个开机提示音乐。
先来个简单粗暴，直接加到rcS脚本后面，
#!/bin/sh /etc/init.d/zqbNetwork start ./zqbMusic kaiji.wav
那么就在五秒多的时候，开始播放，播放完毕六秒多，打印出了"/ #"，这样就比较不好了，我“/ #”之后还要启动其他应用程序呢，放音乐直接延迟了其他事情一秒多。
那么，是不是可以并行呢，考虑了一下，开网络是要时间的，放音乐也要时间，那把一个放到后台去，不要等，应该快些吧。于是改成
#!/bin/sh ./zqbMusic kaiji.wav & /etc/init.d/zqbNetwork start
后面加上 & ，就是后台执行了，也就是另一个进程了。恩，今天想到并行，搜了一下才发现这么简单，加个 & 就可以了，好东西。
这么做了之后，好一些了，五秒多就可以听到声音了，打印“/ #”的时间也在五秒多(比原来慢一些，毕竟多跑了个线程抢资源)
这个时候，忍不住就要想，能不能再往前提，我干脆提到跟init并行，不改文件系统的话，这就是用户空间的极限了吧，一进来就开始播音乐
于是修改掉kernel的CMDLINE,把里面的init=/init 改成 init=/zqbinit，重新编译内核
然后就写个zqbinit.sh，大概是这样
#!/bin/sh ./zqbMusic kaiji.wav &
exec init
搞定，丢到文件系统，烧到板子启动，结果报错了，是一个什么permission denied，具体当时没存下来，大概就是说我没有权限执行 init（实际上是busybox）
尝试了chmod 各种加权限，还是报错，暂时不知道为什么，算了干脆用C试试
于是用C写个很简单的程序，fork一个子进程，子进程去execlp调用zqbMusic，父进程则execlp 调用原本的init
大概是这样
#include <stdio.h> #include <unistd.h> #include <stdlib.h> int main(int argc, char **argv) { pid_t pid; if(pid = fork()) { execlp("./init", "init", NULL); exit(0); } execlp("./zqbMusic", "zqbMusic", "./kaiji.wav",NULL); return 0; }
搞好Makefile，编译出zqbinit，放进去，这回可以用了
结果是，音乐在四秒多就开始播了，原本的init也能正常执行下去最终到达控制台，打印出“/ #”。
不过播放音乐这个进程，抢资源还是比较多，打印“/ #”的时间比没播音乐的情况，延迟了七八百毫秒。但总比串行执行，延迟一秒多，要好些。
而且这么看来，其他应用程序，也不是非得等到“/ #”之后调用，跟这个音乐一起并行嘛，再开个进程，也是个方法。至于到底要不要这么做，那就是另说了，毕竟进程多了切来切去也挺耗资源的。
那能不能再提前？想了下，如果在刚刚那个调用init 的父进程中，来个sleep之类的，主动让资源给zqbMusic，或者有什么小动作提一下优先级，那就是当之无愧的用户空间第一快了。
再提前？再提前就要到内核里面去了，唔，在驱动初始化完毕之后，补一个initcall，就用来放音乐，理论上似乎也是可以的，就是有点别扭。
再提前？把驱动移植到uboot中，没进内核就可以先放开机音乐了，也是一个办法。
再提前，那就太难度了，不如不要放音乐了，弄个蜂鸣器，开机滴一下（突然有种电磁炉即视感……），这个电路应该就能解决吧，绝对快。
本文链接：http://www.cnblogs.com/zqb-all/p/6012087.html