<div dir="ltr">Hi Aleksander,<div><br></div><div>Thank you for the explanation. Here is my understanding and correct me if I am wrong:</div><div><br></div><div>1. In the definition file qmi-service-nas.json</div><div><br></div>
<div>name field "Get System Info"</div><div>type field "Message"</div><div>service field "NAS"</div><div>output field</div><div><br></div><div>These four fields mean the code generator will generate a structure which is named "QmiMessageNasGetSystemInfoOutput", and the other field "id" and "version" are fixed and must not to be modified because they are the only and true QMI message identities.</div>
<div><br></div><div>2. Question about the "type" field. I have read the Qualcomm official QMI NAS API document, the message type of "QMI_NAS_GET_SYS_INFO" (id: 0x004D) is "Request" and another message "QMI_NAS_SYS_INFO_IND" (id: 0x004E) is "Indication". However, in the definition file qmi-service-nas.json, the message type of "System Info" (id: 0x004E) is "Indication" just exactly same as the definition in Qualcomm document, but the message type of "Get System Info" (id: 0x004D) is "Message", not "Request" defined in Qualcomm document. That confused me.</div>
<div><br></div><div>3. Let's go deep in the field "output". What's the meaning / purpose of the sub-filed "common-ref" and its value "Operation Result"?</div><div><br></div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-11 19:41 GMT+08:00 Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">><br>
> Thanks for the explanation. I still have lots questions about the function<br>
> definition in JSON database file. Take the function<br>
> "qmi_client_nas_get_system_info_finish()" as example<br>
><br>
> 1. How is this function generated? I mean which section of the JSON database<br>
> defines this function call.<br>
><br>
<br>
</div>Look at the definition of "Get System Info" in /data/qmi-service-nas.json.<br>
<br>
That definition  has an "output" variable which is a dictionary<br>
containing the possible TLVs that may be available in a "Get System<br>
Info" response. The code generator will take that list of possible<br>
TLVs and generate methods to get the values from a<br>
QmiMessageNasGetSystemInfoOutput object which is generated when the<br>
response is parsed by libqmi. E.g. you will have a<br>
qmi_message_nas_get_system_info_output_get_sim_reject_info() method to<br>
read the contents of the optional "SIM Reject Info" TLV. The<br>
QmiMessageNasGetSystemInfoOutput is the result you'll get in<br>
qmi_client_nas_get_system_info_finish().<br>
<br>
If the QMI message had "input" in addition to "output", you would also<br>
see APIs to manage the contents of the input TLVs passed in the QMI<br>
request. You would be in charge of creating an "Input" bundle object<br>
(e.g. QmiMessageNasConfigSignalInfoInput for the "Config Signal Info"<br>
message), set the corresponding TLVs through the provided APIs (e.g.<br>
qmi_message_nas_config_signal_info_input_set_rscp_threshold()) and<br>
then include that input bundle in the client call (e.g.<br>
qmi_client_nas_config_signal_info()).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aleksander<br>
<a href="https://aleksander.es" target="_blank">https://aleksander.es</a><br>
</font></span></blockquote></div><br></div>