Hi Arron,

On 08.11.2011 10:09, Wang, Arron wrote:
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Patrik Flykt
>> Sent: Tuesday, November 08, 2011 4:54 PM
>> To: [email protected]; Daniel Wagner
>> Subject: Re: [PATCH] session: Reset ecall_info when emergency call app
> exits
>> abnormally
>>
>>
>>      Hi,
>>
>> On Tue, 2011-11-08 at 03:38 -0500, Yu A Wang wrote:
>>> Fixes BMC#23631
>>> ---
>>>  src/session.c |    3 +++
>>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/session.c b/src/session.c
>>> index 83cdaf0..ae3614b 100644
>>> --- a/src/session.c
>>> +++ b/src/session.c
>>> @@ -1407,6 +1407,9 @@ static void owner_disconnect(DBusConnection
>> *conn, void *user_data)
>>>
>>>     DBG("session %p, %s died", session, session->owner);
>>>
>>> +   if (ecall_info != NULL && ecall_info == session->info)
>>> +           ecall_info = NULL;
>>> +
>>>     session_disconnect(session);
>>>  }
>>
>> The behavior on emergency call application exiting abnormally needs
>> input from wagi for defining the expected policy. I could guess the
>> emergency is still ongoing, and thus the emergency application probably
>> needs to be restarted by the system immediately. How the new instance of
>> the emergency app becomes the owner of the ecall is currently unknown
>> and unimplemented.
> 
> When emergency call app runs it will set the EmergencyCall flag whether when
> it first run or restart, then I think it will be ok for us to reset it when
> it exits abnormally. Anyway we need our expert Wagi's advice :-)

The current assumption is that the emergency application runs all the
time. In the case where it crashes it should be restarted immediately
(properly by systemd). The tricky part is when the emergency call
application crashes during an emergency call. In this case we really
should not reset the ecall bit. Instead we should just wait until the
emergency application is back and resumes work. The emergency call
application is really in charge in this case.

First thing to note is that only one emergency call application is
allowed to run at the time. We also have to protect the access to the
EmergencyCall Setting through some means (the proposal is to use
PolicyKit rules for this). If the application dies through the emergency
call and then is restarted we can assign the owner ship to this session.

This ties some behavior interaction down between ConnMan and the
emergency application. I think I should write this down soonish.

Let me finish the ofono plugin rewrite and then I do another update on
the session documentation.

BTW, all of this is not implemented yet. As always, patches are welcomed.

cheers,
daniel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman

Reply via email to