init.svc.*(hostapd, p2p_supplicant) properties are set when starting
STA or uAP via Wi-Fi HAL, after sending ctrl.start command to
property_service, thread called wifi_start_supplicant will yield cpu
for android init process to get scheduled, then init.svc.* status
is read to check if supplicant status is running
there is a chance that after scheld_yield returned, init is not
scheduled, serial value is not updated, __system_property_read got
the "stopped" status, then init is scheduled to update service status
after that back to this loop in Wi-Fi HAL, serial is updated, but
status is not reread, still used "stopped", then Wi-Fi HAL will
report supplicant start failed
as the following schedule sequence:
process A(WifiStateMachine) process B(init)
1. ctl.start
2. scheld_yield
3. __system_proerty_read
/*serial1, value1*/
4. __system_property_update
/*serial2, value2*/
5. serial1 != serial2
6. value1 == "stopped"
So after sched_yield, first check if serial is updated, then read
service status
Change-Id: I5181e0d4504c525832c033b9a35bd58ec63e1de8
Signed-off-by: jiaguo <jiaguo@marvell.com>
pi = __system_property_find(supplicant_prop_name);
}
if (pi != NULL) {
- __system_property_read(pi, NULL, supp_status);
- if (strcmp(supp_status, "running") == 0) {
- return 0;
- } else if (__system_property_serial(pi) != serial &&
- strcmp(supp_status, "stopped") == 0) {
- return -1;
+ /*
+ * property serial updated means that init process is scheduled
+ * after we sched_yield, further property status checking is based on this */
+ if (__system_property_serial(pi) != serial) {
+ __system_property_read(pi, NULL, supp_status);
+ if (strcmp(supp_status, "running") == 0) {
+ return 0;
+ } else if (strcmp(supp_status, "stopped") == 0) {
+ return -1;
+ }
}
}
#else