**** BEGIN LOGGING AT Fri Dec 17 02:59:59 2010
Dec 17 15:30:33 <sameo> wagi: If you can quickly resend #6 with the naming fixed, I'll apply your patchset.
Dec 17 15:33:30 <sameo> argh, wrong channel...
Dec 17 16:27:10 <padovan> denkenz: FYI I have 4 pending patches for oFono, in the case you lost something.
Dec 17 16:32:46 <denkenz> I have Lockdown and 1/2 & 2/2
Dec 17 16:32:58 <denkenz> add support to restore state
Dec 17 16:33:13 <denkenz> what are the other 2?
Dec 17 16:34:38 <padovan> there is only other one: use ofono_error instead of DBG for errors
Dec 17 16:36:06 <denkenz> yeah I just replied to that one
Dec 17 16:39:35 <padovan> bad coccinelle :(
Dec 17 16:42:06 <denkenz> oh it did its job just fine, but not everything's a nail ;)
Dec 17 16:44:58 <padovan>  yep
Dec 17 16:48:56 <denkenz> Can you do me a favor and send a patch marking CNAP task as done?
Dec 17 16:52:04 <padovan> Sure.
Dec 17 17:56:53 <padovan> denkenz: holtmann: for the DUN server task, is there something missing in the AT server or PPP server that I should finish first?
Dec 17 17:57:03 <padovan> Or I can do that on demand?
Dec 17 19:17:13 <padovan> holtmann: denkenz: I have not followed why adding btio to oFono, isn't it better leave the listen part to bluetoothd and pass the client fd via DBus.? What are the reasons?
Dec 17 19:48:31 <denkenz> we considered both, but it might be easier to use btio first
Dec 17 19:50:04 <padovan> and then move to DBus fd passing aftwards?
Dec 17 20:20:18 <padovan> denkenz: and I have doubts on the emulator atom. What kind of things we are planinng to emulate there? Is zhenhua implementantion ok?
Dec 17 20:56:44 <denkenz> padovan: one possibility is to move to fd passing, but we'll cross that bridge when we come to it
Dec 17 20:57:15 <denkenz> padovan: for now we need DUN emulation straight from the BT DUN spec
Dec 17 20:57:20 <denkenz> we can add other commands on top of it
Dec 17 21:04:51 <denkenz> balrog-k1n: Is memset(efmsisdn, 0xff, sim->efmsisdn_length);
Dec 17 21:05:03 <denkenz> kosher inside sim.c set_own_numbers?
Dec 17 21:05:44 <denkenz> to me sounds like the length of bcd / ssc should be 1..
Dec 17 21:08:31 <zrafa> denkenz: I sent a few patches for the gps atom task. I have in my todo list the test script for that as well (which I did not include on those patches)
Dec 17 21:09:51 <denkenz> yes, I know, but I still have ~40 to review besides yours ;)
Dec 17 21:10:30 <zrafa> denkenz: yes, no rush :) I will wait your review and comments before to send the test script
Dec 17 21:11:09 <denkenz> maybe you can convince holtmann to take a look as well
Dec 17 21:12:52 <zrafa> denkenz: yes, I will ping him as well
Dec 17 21:14:31 <balrog-k1n> demarchi: so you're saying that we should write 1 (why not 0?) on the first byte and not care about the other bytes of the record?
Dec 17 21:15:03 <balrog-k1n> sorry, this was for denkenz 
Dec 17 21:15:20 <denkenz> well, this is an EFadn-like record
Dec 17 21:15:37 <denkenz> The BDN / SSC contents are a max of 11 bytes
Dec 17 21:15:49 <denkenz> so putting 0xff does not seem kosher
Dec 17 21:16:43 <balrog-k1n> maybe
Dec 17 21:17:12 <balrog-k1n> although 0xff unmistakably means invalid record, which is what we want
Dec 17 21:17:47 <denkenz> I'm afraid it will screw up lesser parsers
Dec 17 21:20:12 <balrog-k1n> denkenz: true
Dec 17 21:20:44 <balrog-k1n> what do you think about memset(efmsisdn, 0xff, sim->efmsisdn_length); followed by efmsisdn[sim->efmsisdn_length - 14] = 0;?
Dec 17 21:21:34 <denkenz> why 0? it should be 1
Dec 17 21:22:15 <balrog-k1n> because the "BCD number/SSD contents" is empty
Dec 17 21:22:29 <balrog-k1n> *SSC
Dec 17 21:22:33 <denkenz> Yep, but the length also contains the TON / NPI
Dec 17 21:23:03 <denkenz> At least from what I remember
Dec 17 21:23:17 <balrog-k1n> the TON / NPI is also invalid though (we write it with 0xff)
Dec 17 21:23:29 <balrog-k1n> so there's no point in some parser trying to interpret it
Dec 17 21:25:14 <denkenz> hey I agree with you 100%, but lets account for the other monkeys who are not as paranoid ;)
Dec 17 21:25:47 <denkenz> though ton / npi set to 0xff means it is an SSC string
Dec 17 21:26:00 <denkenz> not really 'invalid'
Dec 17 21:26:10 <balrog-k1n> hmm, so you think it could crash some parser if it tries to read -1 bytes of the number string?
Dec 17 21:26:38 <balrog-k1n> would memset(efmsisdn, 0xff, sim->efmsisdn_length); efmsisdn[sim->efmsisdn_length - 14] = 1; work?
Dec 17 21:27:01 <denkenz> I think so
Dec 17 21:27:09 <balrog-k1n> ok
Dec 17 21:52:02 <denkenz> Jeevaka: here?
Dec 18 00:02:11 <Jeevaka> denkenz: ping
Dec 18 00:02:17 <denkenz> pong
Dec 18 00:02:48 <Jeevaka> is it about cfis?
Dec 18 00:03:09 <denkenz> see my reply to the ML
Dec 18 00:04:03 <Jeevaka> noticed. clone didn't get the integrated patch. seems it might taje some time
Dec 18 00:07:16 <Jeevaka> for the first case, if there is no cfis record contaiingn proper msp ids, thenCFU is not actve
Dec 18 00:08:10 <denkenz> sure, but we don't ever write the record in this case
Dec 18 00:08:21 <denkenz> So if e.g. you have a brand new sim, you might have MSP = 255 for all records
Dec 18 00:09:41 <Jeevaka> instead of relying on the record it to write, I should have relied on the file presence
Dec 18 00:09:47 <Jeevaka> id*
Dec 18 00:10:39 <denkenz> it gets tricky actually
Dec 18 00:10:56 <denkenz> there isn't a simple answer, otherwise I would have fixed it ;)
Dec 18 00:11:09 <Jeevaka> ok :)
Dec 18 00:11:13 <denkenz> especially since we do want to support MSP at some point
Dec 18 00:12:25 <denkenz> and also remember that you might have > 4 EFcfis records
Dec 18 00:12:33 <denkenz> with multiple records / MSP
Dec 18 00:12:46 <denkenz> so you need to ever select 1
Dec 18 00:17:07 <Jeevaka> second case, each profile will have only one record. so if we have voice and data active in profile 1, it is still stored as 1record only
Dec 18 00:17:44 <denkenz> nope
Dec 18 00:17:53 <Jeevaka> do you mean to say that there can be multiple records for single profile itself?
Dec 18 00:17:58 <denkenz> yes
Dec 18 00:18:17 <Jeevaka> then may be I understood the spec wrongly
Dec 18 00:18:22 <denkenz> To see why, peek at EFmbdn / EFmsisdn
Dec 18 00:18:42 <denkenz> They do not have a field for MSP, the MSP profile is equivalent to the record number
Dec 18 00:18:47 <denkenz> no to so for EFcfis
Dec 18 00:18:52 <denkenz> err not so
Dec 18 00:19:30 <denkenz> And yes, the spec basically lets you shoot yourself in the foot here ;)
Dec 18 00:21:30 <Jeevaka> thats the usual case when it comes to SIM and SAT
Dec 18 00:21:59 <denkenz> yes, true
Dec 18 00:22:04 <denkenz> But worse than usual in this case ;)
Dec 18 00:25:33 <Jeevaka> stk null text string and icon present is applicable to all the sat pcmds which has alpha identifer or text string and icon
Dec 18 00:26:12 <Jeevaka> this will result in almost all commands to have this check
Dec 18 00:27:16 <Jeevaka> If the terminal receives an icon, and either an empty or no alpha identifier/text string is given by the UICC, than the terminal shall reject the command with general result "Command data not understood by terminal
Dec 18 00:28:03 <Jeevaka> so, what to do now? do we need to add this check for all the applicable PCMDs
Dec 18 00:33:07 <denkenz> I think so
Dec 18 00:33:18 <balrog-k1n> Jeevaka: probably
Dec 18 00:34:38 <balrog-k1n> Jeevaka: by empty do you mean len=0 or len=1 again? :)
Dec 18 00:36:40 <Jeevaka> in this case, its both
Dec 18 00:37:04 <Jeevaka> empty len = 1, null len = 0
Dec 18 00:38:30 <balrog-k1n> why should empty (len = 1) be rejected? iirc TS 102 223 and the test in 102 384 only speak about null (len = 0)
Dec 18 00:40:18 <Jeevaka> but the section 6.5.4, is mentioning about empty or no text string
Dec 18 00:41:52 <balrog-k1n> Jeevaka: sorry, you're right
Dec 18 00:52:47 <Jeevaka> denkenz: I'll deliver the phonesim supprt for cfis tomorrow
Dec 18 00:53:06 <denkenz> no hurry, I don't work on weekends ;)
Dec 18 00:53:10 <Jeevaka> stuck in the airport :)
Dec 18 00:53:27 <denkenz> ah, fair enough
**** ENDING LOGGING AT Sat Dec 18 03:00:01 2010