Hi, Brian and Mike
Thanks for your help, I think I get through my confusion now! I mistake the
code will run into the piece of code bellow for granted. Yes, only the
error condition that should happen.
if (ret == 0 || !(errno == EAGAIN || errno == EINTR)) {
/* fatal error or end-of-stream */
if (ret != 0) {
LOGE("error on reading command socket errno:%d\n", errno);
} else {
LOGW("EOS. Closing command socket.");
}
close(s_fdCommand);
s_fdCommand = -1;
... ...
}
Best Regards,
Johnny Song
2009/5/23 Brian Liu <[email protected]>
>
> The command socket (s_fdCommand) will be closed only when there is any
> exception like EINTR or end of stream (e.g. service layer close this
> socket).
>
> The sequence is like this:
> 1. Bootup
> 1.1 Init process create UNIX domain socket on /dev/socket/rild and
> then fork RILD according to init.rc
> 1.2 RILD get the socket handle (i.e. s_fdListen) and listen on it
> (i.e. put into "select" list)
> 1.3 Service layer (framework/base/telephony/java/com/android/internal/
> telephony/gsm/RIL.java) will connect to RILD via this UNIX domain
> socket (/dev/socket/rild)
> 1.4 Return from "select", RILD will "accept" this connection from
> service layer. A new command socket "f_sdCommand" is returned from
> "accept()"
>
> 2. Handle request or unsolicited indication
> RILD (or more accurately, event loop thread in RILD) will loop endless
> to read/handle request from s_fdCommand connection or write
> unsolicited indication (e.g. RING) to s_fdCommand. The code is like
> this:
> for (;;) {
> /* loop until EAGAIN/EINTR, end of stream, or other error */
> 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);
> }
> }
>
> This means s_fdCommand is a "live" connection until some exception
> (e.g. service layer close connection for some reason). It will NOT be
> closed after each request from service layer.
>
> On May 20, 4:05 pm, Johnny Song <[email protected]> wrote:
> > On Wed, May 20, 2009 at 2:08 PM, Michael Trimarchi <
> >
> >
> >
> >
> >
> > [email protected]> wrote:
> >
> > > Song Johnny wrote:
> > > > to be more, I wonder service layer will keep connecting the rild
> > > > socket so that the rild daemon listen thread will accept and build
> the
> > > > connection, but did that way work inefficiently?
> >
> > > > On Tue, May 19, 2009 at 2:15 PM, Song Johnny <[email protected]
> > > > <mailto:[email protected]>>
> > > > wrote:
> >
> > > > Hi,
> >
> > > > Now I am looking RILD system in Android. I have got some idea
> > > > about the processing in RILD. when dailing, phone service will
> > > > process dail request and then get the rild socket to connect with
> > > > rild daemon. After connection, service layer will transfer the
> > > > data package to rild daemon, and rild daemon will process the
> > > > information included in the data package then rild daemon opens
> > > > ttyS device to comunicate with modem.
> >
> > > > To me, after response, rild daemon will send the data from modem
> > > > to service layer through the same rild socket. and that's the
> big
> > > > picture of the whole procesure about RILD to process dail
> request.
> >
> > > > BUT, after that, rild daemon will close the rild socket, which
> > > > means there is no permanent connection between phone service and
> > > > rild daemon. So, I cannot figure out the case when incoming
> call,
> > > > how RILD would process the information and send it to phone
> > > > service! because I have not found the socket connection request
> in
> > > > RILD source.
> >
> > > Have you take a look at libril/ril.cpp. That file contains the message
> > > communition between
> > > the rild and upper layer.
> > > Michael
> >
> > Hi, Michael,
> >
> > Thanks for your information.
> >
> > I have gone through libril source files. in libril/ril.cpp, the function
> > sendResponseRaw() will call write() to fd s_fdCommand, which was the
> socket
> > fd got after accepting from the listen routine. further more,
> > processCommandsCallback() will close s_fdCommand and delete this command
> > event from ril event list.
> >
> > until now, I found this fd, s_fdCommand, is the only connection socket
> fd.
> > and it is got when got upper layer connecting request. but my concern is
> > how the RILD processing incoming call. there seems no socket connection
> > between rild daemon and upper layer in this scenario!!
> >
> > Best Regards,
> > Johnny Song
> >
> > From China.
> >
>
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
