（2）RIL简析（高通）——消息处理

• RIL如何启动及初始化？

• RILJ的消息如何传递和被处理？

  • event table的定义
  • requested event的处理函数
  • ril_event的管理
  • RIL_REQEUST执行结果的返回
  • RIL_UNSOL类型消息的上报

• 一个消息处理的具体例子——SETUP_DATA_CALL

• 如何添加一个RIL消息和对应的处理函数？

---

event table的定义

RIL所有的EVENT都定义在Ril.h中，有以RIL_REQUEST和RIL_UNSOL_RESPONSE开头的消息，前者代表主动请求，后者一般是上报的消息，例如下面这2个：

#define RIL_REQUEST_SETUP_DATA_CALL 27
#define RIL_UNSOL_RESPONSE_RADIO_STATE_CHANGED 1000

当然，无论是REQUEST还是UNSOL_RESPONSE都会带参数，因此还需定义消息对应的结构体，例如RADIO_STATE的结构体：

typedef enum {    RADIO_STATE_OFF = 0,                   /* Radio explictly powered off (eg CFUN=0) */    RADIO_STATE_UNAVAILABLE = 1,           /* Radio unavailable (eg, resetting or not booted) */    /* States 2-9 below are deprecated. Just leaving them here for backward compatibility. */    RADIO_STATE_SIM_NOT_READY = 2,         /* Radio is on, but the SIM interface is not ready */    RADIO_STATE_SIM_LOCKED_OR_ABSENT = 3,  /* SIM PIN locked, PUK required, network                                              personalization locked, or SIM absent */    RADIO_STATE_SIM_READY = 4,             /* Radio is on and SIM interface is available */    RADIO_STATE_RUIM_NOT_READY = 5,        /* Radio is on, but the RUIM interface is not ready */    RADIO_STATE_RUIM_READY = 6,            /* Radio is on and the RUIM interface is available */    RADIO_STATE_RUIM_LOCKED_OR_ABSENT = 7, /* RUIM PIN locked, PUK required, network                                              personalization locked, or RUIM absent */    RADIO_STATE_NV_NOT_READY = 8,          /* Radio is on, but the NV interface is not available */    RADIO_STATE_NV_READY = 9,              /* Radio is on and the NV interface is available */    RADIO_STATE_ON = 10                    /* Radio is on */} RIL_RadioState;

通过搜索，发现ril_commands.h中还有定义RIL_REQUEST的数组元素，字面意思来看，明显是消息处理入口和返回的函数入口：
{RIL_REQUEST_SETUP_DATA_CALL, dispatchDataCall, responseSetupDataCall}

ril.cpp居然直接引入了这些定义，所有消息和对应的函数都存在s_commands数组里了：

ril.cpptypedef struct {   int requestNumber;   void (*dispatchFunction) (Parcel &p, struct RequestInfo *pRI);   int (*responseFunction) (Parcel &p, void *response, size_t responselen);} CommandInfo;static CommandInfo s_commands[] = {#include "ril_commands.h"};

那么，这些消息对应的函数是怎样被匹配并对应执行的呢？下一节。

---

requested event的处理

我们要看消息是如何被处理的，先从消息的监听入手，就应该能找到对应的处理函数了。
既然这些消息是上层下发的，那么RIL就是通过socket来接收到消息。先回顾下socket监听是怎样建立的，应该就能找到消息处理的入口。
上一篇有讲到，RIL_register有监听RILD socket的代码：

ril.cpp::RIL_register    /* Initialize socket1 parameters */    s_ril_param_socket = {                        RIL_SOCKET_1,             /* socket_id */                        -1,                       /* fdListen */                        -1,                       /* fdCommand */                        PHONE_PROCESS,            /* processName */                        &s_commands_event,        /* commands_event */                        &s_listen_event,          /* listen_event */                        processCommandsCallback,                          NULL                      /* p_rs */    startListen(RIL_SOCKET_1, &s_ril_param_socket);

startListen函数获取到socket的fd，初始化event并加入到eventloop，回调为listenCallback：

    fdListen = android_get_control_socket(socket_name);    ret = listen(fdListen, 4);    socket_listen_p->fdListen = fdListen;    ril_event_set (socket_listen_p->listen_event, fdListen, false,                listenCallback, socket_listen_p);    rilEventAddWakeup (socket_listen_p->listen_event);

listenCallback再次向eventloop加入event，这次event的persistence值为1，回调为processCommandsCallback：

Ril::listenCallback()//persist值为1，eventloop会一直监听这个fdril_event_set (p_info->commands_event, p_info->fdCommand, 1,p_info->processCommandsCallback, p_info);rilEventAddWakeup (p_info->commands_event);  

event的persistence值为1，ev->fd会一直存在于readFds集合，eventloop因此会持续监听socket。persist值的实际逻辑后面再来讲。

继续先看看processCommandsCallback这个函数跟event的处理有没有关系，一看果然没让我失望：

ril::processCommandsCallback(int fd, short flags, void *param){    for (;;) {        //从fd读取数据，应该是event的数据        ret = record_stream_get_next(p_rs, &p_record, &recordlen);        if (ret == 0 && p_record == NULL) {            /* end-of-stream */            break;        } else if (ret < 0) {            break;        } else if (ret == 0) { /* && p_record != NULL */            //数据传入这个函数，继续深入            processCommandBuffer(p_record, recordlen, p_info->socket_id);        }    }}//分发消息ril::processCommandBuffer(void *buffer, size_t buflen, RIL_SOCKET_ID socket_id){    Parcel p;    status_t status;    int32_t request;    int32_t token;    RequestInfo *pRI;    int ret;    /* Hook for current context */    /* pendingRequestsMutextHook refer to &s_pendingRequestsMutex */    pthread_mutex_t* pendingRequestsMutexHook = &s_pendingRequestsMutex;    /* pendingRequestsHook refer to &s_pendingRequests */    RequestInfo**    pendingRequestsHook = &s_pendingRequests;    p.setData((uint8_t *) buffer, buflen);    status = p.readInt32(&request);    status = p.readInt32 (&token);    pRI = (RequestInfo *)calloc(1, sizeof(RequestInfo));    pRI->token = token;    pRI->pCI = &(s_commands[request]); //获取消息对应的结构体成员    pRI->socket_id = socket_id;    pRI->p_next = *pendingRequestsHook;    pRI->pCI->dispatchFunction(p, pRI); //分发消息到对应的消息}

消息处理的地方就在processCommandBuffer，使用ID匹配到对应的s_commands成员，调用对应的处理函数。

消息定义、监听和分发消息的地方都找到了，接下来再看看ril_event_loop有哪些具体的处理：

ril_event.cppvoid ril_event_loop(){    int n;    fd_set rfds;    struct timeval tv;    struct timeval * ptv;    for (;;) {        //make local copy of read fd_set        memcpy(&rfds, &readFds, sizeof(fd_set));        if (-1 == calcNextTimeout(&tv)) {            // no pending timers; block indefinitely            ptv = NULL;        } else {            ptv = &tv;        }        //select轮询fd_set集合IO状态        n = select(nfds, &rfds, NULL, NULL, ptv);        if (n < 0) {            if (errno == EINTR) continue;            return;        }        // Check for timeouts        processTimeouts();        // Check for read-ready        processReadReadies(&rfds, n);        // Fire away        firePending();    }}

select返回值后，执行了3个函数：processTimeouts()/processReadReadies(&rfds, n)/firePending()，挨个看。

processTimeouts()检查timer_list是否有超时项，如果有则加入到pending_list：

static void processTimeouts(){    struct timeval now;    struct ril_event * tev = timer_list.next;    struct ril_event * next;    getNow(&now);    while ((tev != &timer_list) && (timercmp(&now, &tev->timeout, >))) {        // Timer expired        next = tev->next;        //移除event        removeFromList(tev);        //将event加入pending_list        addToList(tev, &pending_list);        tev = next;    }}

processReadReadies 从watch_table获取到对应的event，并加入到pending_list。

static void processReadReadies(fd_set * rfds, int n){    for (int i = 0; (i < MAX_FD_EVENTS) && (n > 0); i++) {        struct ril_event * rev = watch_table[i];        if (rev != NULL && FD_ISSET(rev->fd, rfds)) {            addToList(rev, &pending_list);            if (rev->persist == false) {                removeWatch(rev, i);            }            n--;        }    }}

之前讲到event的persistence值，正是在processReadReadies里面用到，作用是控制event是否在触发后从watch_table移除，rild socket的监听设置persistence=1，因此其fd不会在这个被移除掉。

firePending()将event从pending_list移除出去，并调用ev->func执行消息处理：

static void firePending(){    struct ril_event * ev = pending_list.next;    while (ev != &pending_list) {        struct ril_event * next = ev->next;        removeFromList(ev);        ev->func(ev->fd, 0, ev->param);        ev = next;    }}

ev->func对应什么函数？
还记得前面设置rild socket监听的时候，event参数是：

ril_event_set (p_info->commands_event, p_info->fdCommand, 1, p_info->processCommandsCallback, p_info);

ev->func就是processCommandsCallback，没错，接着就是从s_commands里面找到对应的event：
pRI->pCI->dispatchFunction(p, pRI);

然后dispatchFunction:
{RIL_REQUEST_SETUP_DATA_CALL, dispatchDataCall, responseSetupDataCall}

responseSetupDataCall处理完成继续将数据传到下一个函数dispatchStrings

#define CALL_ONREQUEST(a, b, c, d, e) s_callbacks.onRequest((a), (b), (c), (d), (e))static void dispatchStrings (Parcel &p, RequestInfo *pRI) {    CALL_ONREQUEST(pRI->pCI->requestNumber, pStrings, datalen, pRI, pRI->socket_id);}

后面就是执行qcril onRequest函数，每个消息具体处理都有所不同，这里先作抛砖引玉。

至于上面提及的watch_table、pending_list还有对这些list的操作addToList等等，他们作用是什么，接着下一节来说。

---

ril_event的管理

在eventloop里面实际操作的是几个ril_event结构体数组和指针，来看看究竟用途是什么。

ril_event.cpp里面有3个与ril_event有关的list，还有4个list的操作函数：

static struct ril_event * watch_table[MAX_FD_EVENTS];static struct ril_event timer_list;static struct ril_event pending_list;static void addToList(struct ril_event * ev, struct ril_event * list);static void removeFromList(struct ril_event * ev);static void removeWatch(struct ril_event * ev, int index);void ril_timer_add(struct ril_event * ev, struct timeval * tv);

addToList，加入一个event，ril_event通过链表方式保存：

static void addToList(struct ril_event * ev, struct ril_event * list){    ev->next = list;    ev->prev = list->prev;    ev->prev->next = ev;    list->prev = ev;    dump_event(ev);}//将ril_event移除static void removeFromList(struct ril_event * ev){    ev->next->prev = ev->prev;    ev->prev->next = ev->next;    ev->next = NULL;    ev->prev = NULL;}

watch_table是ril_event类型的数组，ril_event有fd和callback等字段，可见watch_table只是作为保存“监听器”之用，而真正要被处理的消息是在callback函数中从fd stream读取，个人觉得ril_event的命名有点不太准确了：

ril_event.hstruct ril_event {    struct ril_event *next;    struct ril_event *prev;    int fd;    int index;    bool persist;    struct timeval timeout;    ril_event_cb func;    void *param;};

pending_list是即将回调（ev->func）的ril_event 列表，可以理解成被触发的监听器列表，ril_event处理后会从pending_list移除掉。

timer_list 设置了timeout的ril_event列表，从processTimeouts()函数可看出，超时的ril_event都会加进pending_list。

小结：
ril_event作用相当于监听器，并非实际的事件；
存在于watchtable中的ril_event提供了读写event的fd和callback函数，是事件处理的入口；
pending_list负责存放即将被处理的ril_event。

---

RIL_REQEUST执行结果的返回

消息处理完成，如何返回结果呢？
回想ril_commands.h里的定义：
{RIL_REQUEST_SETUP_DATA_CALL, dispatchDataCall, responseSetupDataCall}

responseSetupDataCall应该就是用来返回结果的，对应函数入口是responseFunction

typedef struct {    int requestNumber;    void (*dispatchFunction) (Parcel &p, struct RequestInfo *pRI);    int(*responseFunction) (Parcel &p, void *response, size_t responselen);} CommandInfo;

来搜索下调用responseFunction的地方

ril.cppRIL_onRequestComplete(RIL_Token t, RIL_Errno e, void *response, size_t responselen) {    RequestInfo *pRI;    int ret;    int fd = s_ril_param_socket.fdCommand;    size_t errorOffset;    RIL_SOCKET_ID socket_id = RIL_SOCKET_1;    pRI = (RequestInfo *)t;    if (pRI->cancelled == 0) {        Parcel p;        p.writeInt32 (RESPONSE_SOLICITED);        p.writeInt32 (pRI->token);        errorOffset = p.dataPosition();        p.writeInt32 (e);        if (response != NULL) {            //pRI->pCI->responseFunction并获得返回值            ret = pRI->pCI->responseFunction(p, response, responselen);            /* if an error occurred, rewind and mark it */            //写入返回值到parcel            if (ret != 0) {                p.setDataPosition(errorOffset);                p.writeInt32 (ret);            }        }        //返回parcel        sendResponse(p, socket_id);    }}

上一篇文章提过，RIL_onRequestComplete函数是s_rilEnv 的一个成员，RIL_init第一个参数就是s_rilEnv，可以推测是提供给qcril做回调函数之用：

rild.cstatic struct RIL_Env s_rilEnv = {    RIL_onRequestComplete,    RIL_onUnsolicitedResponse,    RIL_requestTimedCallback};

ril.hstruct RIL_Env {    void (*OnRequestComplete)(RIL_Token t, RIL_Errno e,                           void *response, size_t responselen);    void (*OnUnsolicitedResponse)(int unsolResponse, const void *data, size_t datalen, RIL_SOCKET_ID socket_id);    void (*RequestTimedCallback) (RIL_TimedCallback callback,                                   void *param, const struct timeval *relativeTime);};

查找到OnRequestComplete的调用者是qcril.c 的qmi_ril_fw_send_request_response_epilog函数

if (token && !qcril_is_internal_token(token))  {    qcril_response_api[ instance_id ]->OnRequestComplete( token,                                                          resp_cause,                                                          resp_data,                                                          resp_data_len );  }

找到了返回结果的地方，继续寻找返回数据的地方，既然监听到消息时是从fd读取出来消息，那么返回数据应该就是往fd写入数据。
回头再继续看pRI->pCI->responseFunction，还是以RIL_REQUEST_SETUP_DATA_CALL为例：
{RIL_REQUEST_SETUP_DATA_CALL, dispatchDataCall, responseSetupDataCall}

responseSetupDataCall调用了responseDataCallList，只是往parcel里面增加数据，并没有在这里向fd写入数据

static int responseDataCallList(Parcel &p, void *response, size_t responselen){        RIL_Data_Call_Response_v11 *p_cur = (RIL_Data_Call_Response_v11 *)         int i;        for (i = 0; i < num; i++) {            p.writeInt32((int)p_cur[i].status);            p.writeInt32(p_cur[i].suggestedRetryTime);            p.writeInt32(p_cur[i].cid);            p.writeInt32(p_cur[i].active);            writeStringToParcel(p, p_cur[i].type);            writeStringToParcel(p, p_cur[i].ifname);            writeStringToParcel(p, p_cur[i].addresses);            writeStringToParcel(p, p_cur[i].dnses);            writeStringToParcel(p, p_cur[i].gateways);            writeStringToParcel(p, p_cur[i].pcscf);            p.writeInt32(p_cur[i].mtu);         }}

函数返回到RIL_onRequestComplete，最后调用的函数是sendResponse，这里就是返回数据的地方：

static intsendResponseRaw (const void *data, size_t dataSize, RIL_SOCKET_ID socket_id) {    int fd = s_ril_param_socket.fdCommand;    int ret;    uint32_t header;    header = htonl(dataSize);    ret = blockingWrite(fd, (void *)&header, sizeof(header));    ret = blockingWrite(fd, data, dataSize);}

小结：
qcril.c完成处理后，调用RIL_onRequestComplete返回处理结果；
responseFunction将数据写入parcel;
RIL_onRequestComplete调用sendResponse，向socket的fd写入数据，返回到上层。

---

RIL_UNSOL_RESPONSE

这是一条RIL_UNSOL_RESPONSE消息：
{RIL_UNSOL_RESPONSE_RADIO_STATE_CHANGED, responseVoid, WAKE_PARTIAL},

RIL_UNSOL对应关系定义在ril_unsol_commands.h中，并存到s_unsolResponses数组：

ril.cppstatic UnsolResponseInfo s_unsolResponses[] = {#include "ril_unsol_commands.h"};//UnsolResponseInfo结构体typedef struct {    int requestNumber;    int (*responseFunction) (Parcel &p, void *response, size_t responselen);    WakeType wakeType;} UnsolResponseInfo;

类似于CommandInfo结构体，UnsolResponseInfo结构体也有responseFunction，但没有dispatchFunction。RIL_onUnsolicitedResponse会调用responseFunction处理parcel的数据，然后通过sendResponse返回数据到上层

ril.cppvoid RIL_onUnsolicitedResponse(int unsolResponse, const void *data, size_t datalen){    Parcel p;    p.writeInt32 (RESPONSE_UNSOLICITED);    p.writeInt32 (unsolResponse);    ret = s_unsolResponses[unsolResponseIndex]                .responseFunction(p, const_cast<void*>(data), datalen);    ret = sendResponse(p, soc_id);}

调用这个RIL_onUnsolicitedResponse还是在qcril.c，qcril_send_unsol_response_epilog函数中：

qcril.cif ( param_ptr->instance_id < QCRIL_MAX_INSTANCE_ID )  {    qcril_response_api[ param_ptr->instance_id ]->OnUnsolicitedResponse( param_ptr->response_id, param_ptr->resp_pkt, param_ptr->resp_len );  }

小结：
Unsolicited消息上报的路径类似于RIL_REQUEST，只是调用的函数不一样。

---

总结下：
本篇主要分析了RIL消息接收（RIL_REQUEST）和上报（RIL_UNSOL_RESPONSE），消息处理函数，还有eventloop中监听和分发的逻辑等代码。RILJ部分代码比较清晰好理解，有机会后面再补充。

下一篇具体分析一下SETUP_DATA_CALL是如何建立一个数据连接的。