RE: [PATCH 0/1] stk: Handle send ss proactive command

Hi Yang, D-Bus, a series of functions would be called. For example, if we want to send a call barring activatioin string via D-Bus, these ussd_initiate()->recognized_control_string()->cb_ss_control()->cb_ss_set _lock_callback()->cb_ss_query_next_lock()->cb_ss_query_next_lock_callbac k(). To handle send ss command > from SIM needs to follow the same way as D-Bus, so my target is to try the best to reuse these functions. However, currently these functions take the assumption that the calling is from D-Bus. My replace original "DBusMessage *" parameter. handle them centrally. Following the same control flow as normal case, requires rewriting some of the existing functions to deal with both the cases like what you have done now. Isn't it better to keep it separate? So that we won't end up in introducing SAT specific handling in the normal use case also. Proposed solution: SS(eg: call forwarding, call barring) registers to the USSD by calling __ofono_ussd_ssc_register with the service code, call back function(normal_callback) and few other parameters. SS can also register to the STK by calling __ofono_ussd_ssc_register with the service code, call back function(stk_callback). normal_callback and stk_callback can handle normal and stk use case respectively. More generic handling can be moved to a separate function which normal_callback and stk_callback functions can make use of. Also parsing/matching of the service strings can be moved to utility. STK, USSD or anyother atoms can make use of the parsing/matching(of service string) utility function. Let me know your views on this. Thanks and Regards, jeevaka