前记：
这是我好多年前写的一个文档了。有一年没有做modem侧了，最近一直在做AP原生拨号盘和框架。发现自己原来比较喜欢看协议文档，也喜欢对着协议看代码实现。看一个协议的过程中，总是发现原来还有更多相关协议需要了解。一个还没看完，待看列表却已经越变越长。就像是一个一个散落丝，等待着织成一个网。
整个科技社会中，我就是一个渺小的蚂蚁，提不出创新。但是我仍然尽力学着别人发明创造的东西，尽可能的实现或优化这庞然高塔的某个细小螺丝。
后面陆续将自己之前的一些文档传上来吧。也算是自己的心血了。
正文开始:
1．Ril侧
Android侧通过如下ril命令通知终端获取当前网络列表：
此命令发出后等待cm ph 时间：
。这个事件会列举当前网络列表。
然后此ril命令变为
状态。
见下图：
此ril命令远程调用modem侧的
函数。
要等到ril侧收到
cm事件，此ril命令才完成。
2．Modem侧收到
通过此函数发出
，最终处理此命令的是函数
。此函数会调用mmoc模块的
函数。
函数发出命令
，type为
。
3．Mmoc模块处理
函数处理命令
，当为
时，调用
------>
函数通过
，发送
给 SD模块 。
4．SD模块处理
事件
的枚举值是9，下面的log显示出sd模块对此event的处理
从上图看出，SD脚本查找到脚本73符合要求。在中
，第73个脚本是
。
脚本的入口的条件是
。即
5．SD脚本调用
6. 
对
的处理
从脚本里取一行一行的cons处理。有个
循环，一般cons的处理都回返回
，所以脚本会一行一行的执行。
函数 处理到
时， 调用
。然后
调用 
。
中最后如下：
当return为
，则是指去脚本的下一个cons，在当前脚本中为
。
不过
的处理是，返回了
，
不满足while循环条件，即脚本不继续执行，而是产生了一个action给sd engine。退出函数
，返回
。
5.
处理
实际上是在
里的一个死循环里，
但是
会退出死循环，
7．最终函数一步步回退到
双卡时，每个卡各有自己的stack,即sdss_eng_stack_s实例。即各有自己的sd脚本处理堆栈。
之前的流程简单说一下：
发送命令，cm的
处理命令。
调用
函数，发送mmoc命令。Mmoc通过
处理
命令。
到了
，开始进入sd模块。这个没有命令的转发了，是函数的层层调用。我们看看sd的函数调用层次：
---------------------------------------------------------------
1.
------------------------------------------------------------------
2
----------------------------------------------------------------------
3
----------------------------------------------------------------------------------------------
4
---------------------------------------------------------------------------------------------
5
---------------------------------------------------------------------------------------------------------
6
整个执行流程我画了一个图:
如下:
SD是个脚本和数据库的组合。脚本的执行基于栈的原理，脚本的每行执行相当于压栈，一个脚本执行完了，就会将脚本从栈里弹出。
目前我知道的是新脚本的执行是事件触发的。因为每个脚本的第一行都是对event的判断，那个event匹配了，这个脚本就会被压栈并执行。
特列是：dssscr_called_tbl，这个组里面的脚本是被其他脚本调用的脚本，这些脚本不对event进行判断。
脚本是分组排序的，总共有如下几组脚本：
