Hi,<br><br>I am OK with your ideas, with some remarks:<br><br>- please rename WRITE to UPDATE. Writing is the process of flipping bits from "0" to "1" in a file, resulting in a logical OR between the old data and the new data (AND-writing also exists). An erase is needed to flip these bits to zero. Update is the process of overwriting old data with new data. The concepts are clearly separated in ISO7816, and the GSM 11.11 spec does not support writing to a SIM but only updating (which is good :)). This is only a wording issue, and I will not kill a kitten if someone prefers to keep the "write" wording.<br>
<br>- the uint16_t file shall be a path, ie uint16_t path[MAX_SIM_PATH_LENGTH] where MAX_SIM_PATH_LENGTH is a small constant, ie 4 or 6.<br>rationale: normal UICCs only have a single telecom and a single gsm DF. But we might want to develop multi-DF SIMs, ie one DF for the normal carrier, and another one for an OpenBSC network. Storing a file_id and a df_id is another option, but DFs can be nested so I don't like it because it's too restrictive.<br>
<br>-what about incoming data? This should be stored inside the job. On an update job, the callback will tell you that the update was completed, but you have to send the data anyway. Let's call that the job payload. Unfortunately GSM11.11 tells that updates can be 255 bytes long, which is annoying if such a long buffer is needed, I agree. Something smaller may fit, we will never update 255 bytes at once. The offset at which to update must be also stored. GSMKEY and PIN operations will also need this incoming data.<br>
<br>-what about PIN presentation? This should be a separate job type, with the PIN code as job payload. Okay, this is not needed in a first version.<br><br>-there are two file types. Transparent and record files. The first one are "classic" files, the other are typically accessed one record at a time (e.g. phonebook entries) What about these access differences? We can abstract this differences if we know the record size via a separate call or job type.<br>
<br>Regards<br>Sebastien<br><br><div class="gmail_quote">On Tue, Aug 17, 2010 at 5:33 PM, Andreas.Eversberg <span dir="ltr"><<a href="mailto:Andreas.Eversberg@versatel.de" target="_blank">Andreas.Eversberg@versatel.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div><font face="Arial" size="2"><span>hi,</span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span>i like to write the
sim client protocol. i do not mean the code of the "sim reader" which
is part of layer1 inside the phone. before i start, i would like to know
what you think about my api idea. the api is not the low-level api between
layer1 and the mobile application (APDU layer). it describes a higher layer
for application or protocol processes which need to request IMSI, do
key generation, or store location area information.</span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span>one important thing
is that different processes must be able request "read", "write", or
other operations like key generation simultaniously. in order to handle multiple
requests after each other, a queue inside sim client must exist. afterwar
processing each request, the result must be sent only to the requesting
process (if it still exists). <span>a state
machine watches over the current DF (current selected file area of the sim) and
changes current "DF" if required, before processing read or write job. also it
triggers the next job in the queue, if finished with the current
one.</span></span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span><b>int handle =
sim_open(void (*cb)(...))</b></span></font></div>
<div><font face="Arial" size="2"><span></span></font><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span>will add a new user
instance. cb is the function to be called for response, handle is a unique id of
the process (not a memory pointer, unique at all times after starting
phone).</span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span><b>void
sim_job(struct msgb *msg)</b></span></font></div>
<div><font face="Arial" size="2"><span><b></b></span></font> </div>
<div><font face="Arial" size="2"><span><b>struct
sim_job_hdr {</b></span></font></div>
<div><font face="Arial" size="2"><span><b> int
handle;</b></span></font></div>
<div><font face="Arial" size="2"><span><b> uint8_t
job_type;</b></span></font></div>
<div><font face="Arial" size="2"><span><b> uint16_t
file;</b></span></font></div>
<div><font face="Arial" size="2"><span><b>};</b></span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span>will add a new job.
the type defines the job type. examples are "READ" "WRITE" or "GSMKEY" requests.
the handle is used to assign the read/write job to an instance. the file is used
to select the correct data file of the sim. the data and len represent the data
to be written.</span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span><b>void
cb(struct msgb *msg)</b></span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span>is called back by
the sim client when job is done. the handle is given, so multiple user
instances may use the same callback.</span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span><b>void
sim_close(int handle)</b></span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span>will remove user
instance. outstanding jobs will finish, but no result is given,
because cb is now unregistered.</span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span>the coding and
decoding of SIM files must be done by the application or protocol layer that use
the sim client.</span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span></span></font> </div>
<div><font face="Arial" size="2"><span>andreas</span></font></div>
<div><font face="Arial" size="2"><span></span></font> </div></div>
</blockquote></div><br>