從高通手動搜網代碼流程看sd腳本的執行1．Ril側2．Modem側收到3．Mmoc子產品處理4．SD子產品處理事件

前記：

這是我好多年前寫的一個文檔了。有一年沒有做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進行判斷。

腳本是分組排序的，總共有如下幾組腳本：