**** BEGIN LOGGING AT Tue Jan 18 02:59:57 2011 Jan 18 07:51:27 akiniemi: ping Jan 18 07:55:57 Jeevaka: pong Jan 18 07:56:26 one comment on TODO: Add task for adding EFcsp support patch Jan 18 07:56:42 shoot Jan 18 07:57:35 http://pastebin.com/XH12Patq Jan 18 07:58:58 basically removed "and" Jan 18 08:01:29 and also it would be nice if there is a reference to the CPHS specification Jan 18 08:02:38 Jeevaka: probably needs to be added under specifications Jan 18 08:03:37 akiniemi: agree Jan 18 08:03:43 Jeevaka: I updated the text a bit: http://pastebin.com/JWSnfdBr Jan 18 08:08:45 akiniemi: Is there any change? I'm not able to find the difference Jan 18 08:11:11 Jeevaka: Hmm... I thought you had edited a previous version I had that included the word 'therein' Jan 18 08:12:16 But I suppose not. I can't wrap my head around anything that isn't a git-format-patch result any more ;) Jan 18 08:15:11 Jeevaka: Ah, you edited my commit history. ;) Jan 18 08:15:12 anyway, I dont have anything against the patch Jan 18 08:15:17 yes Jan 18 08:15:28 Jeevaka: ok, good. Jan 18 11:58:41 holtmann: what command did you use to gather the statistics values for ofono and connman projects? Jan 18 11:59:01 holtmann: the values i'm getting are not the same Jan 18 11:59:35 demarchi: gitdm Jan 18 11:59:49 With custom config for companies and personal emails. Jan 18 12:00:34 holtmann: humn.. great, i didn't know that too Jan 18 12:00:37 *tool Jan 18 12:01:19 It counts changed lines and not just commit messages. Jan 18 12:01:49 It does commits as well, but that is not really great for people that do a lot of work, but not many commits. Like new files etc. Jan 18 12:02:54 strange that numbers are a bit different if i use only git + awk Jan 18 12:03:33 holtmann: you counted only the changes from 2010/01/01 to 2010/12/26, right? Jan 18 12:03:52 Nope. Overall from the origin Jan 18 12:04:14 Developers with the most changesets Jan 18 12:04:14 Denis Kenzior 2144 (48.4%) Jan 18 12:04:14 Marcel Holtmann 713 (16.1%) Jan 18 12:04:23 Developers with the most changed lines Jan 18 12:04:23 Denis Kenzior 80165 (33.4%) Jan 18 12:04:24 Andrzej Zaborowski 28019 (11.7%) Jan 18 12:04:30 To see the difference it makes. Jan 18 12:04:54 I have 16% of the commits, but only 10% of changed code. While Andrew beats me there. Jan 18 12:05:08 Same goes for Denis. He has half of the commits, but only 1/3 of the code base. Jan 18 12:05:30 If you have a lot of re-writes and deleted code, the numbers get a bit more trickier. Jan 18 12:06:13 humn... so is this the current snapshot or is it the counting of lines changed on each commit? Jan 18 12:06:37 That is from today., Jan 18 12:07:16 e.g.: if i do 1 commit changing 1 line, and after do another commit changing the same line... it's accounting for 1 line change, right? Jan 18 12:07:29 Nope. It counts as 2 lines. Jan 18 12:08:08 It measures amount of changes. So essentially you can cheat here, but in reality that only happens rarely since you fall through during code review. Jan 18 12:08:49 yeah... right Jan 18 12:09:07 Developers with the most lines removed Jan 18 12:09:07 Marit Henriksen 16 (0.0%) Jan 18 12:09:07 Thadeu Lima de Souza Cascardo 6 (0.0%) Jan 18 12:09:07 Antti Paila 1 (0.0%) Jan 18 12:09:12 It measures also this ;) Jan 18 12:10:04 holtmann: i have one question Jan 18 12:11:27 is there any way way to apply the patches directly from the email Jan 18 12:11:59 Jeevaka: sure, why not? Jan 18 12:12:11 Jeevaka: git am Jan 18 12:12:33 holtmann: there's something wrong with these number... only 16 lines? Jan 18 12:12:53 thanks demarchi Jan 18 12:14:29 demarchi: Don't ask me on how it counts these. Jan 18 12:15:10 demarchi: whats ur call on the memory allocation for cbd in at_pin_retries_query Jan 18 12:15:10 Jeevaka: Yes, we are using "git am" which can take email sources. So you can just save the email in raw format and apply it. It also can take a whole set of emails saved as mbox format. Jan 18 12:15:31 Jeevaka: am means apply mailbox btw. It is Torvalds acronym ;) Jan 18 12:16:06 holtmann: am sounds reasonable :) Jan 18 12:50:44 holtmann: any objection to pushing the patch for CPHS CSP task? Jan 18 12:52:18 I am behind the oFono mailing list. Let me have a look. Jan 18 12:56:48 akiniemi: No problems with pushing that TODO patch. To be honest, I have not looked into CSP at all. I didn't even know that manual network selection could be disable via the SIM card ;) Jan 18 12:57:58 holtmann: Me neither, until we got a failed operator case for that ;) Jan 18 12:58:23 Which operator is that? Jan 18 12:58:27 holtmann: BTW, that file needs to be refreshed, too Jan 18 12:58:50 holtmann: Apparently they have a sim app that can enable manual mode when roaming Jan 18 12:58:51 Sync with Andrew on that. He works on the STK Refresh stuff. Jan 18 12:59:02 holtmann: ack Jan 18 12:59:11 holtmann: a major US carrier ;-) Jan 18 12:59:19 I would have bet on Italy. Jan 18 13:00:08 holtmann: I also have an orange SIM that has the bit, but just not set (= manual mode allowed) Jan 18 13:00:14 To be honest, I have no idea which one. Both are insane. Jan 18 13:00:30 Orange FR or Orange UK? Jan 18 13:00:47 I have a bunch of Orange FR pre-paid SIM cards. Jan 18 13:01:42 holtmann: to be honest, I don't know, I just grabbed this randomly from our SIM library, as it had the CSP file :) Jan 18 13:02:37 holtmann, akiniemi: since the EFcsp file is updatable, you can try updating the corresponding bit **** BEGIN LOGGING AT Tue Jan 18 14:13:58 2011 Jan 18 14:32:41 holtmann: can i fix huawei style issue as part of the same ifx patch or new coding style fix patch Jan 18 14:38:01 Jeevaka: separate ones please. First fix existing style. Jan 18 15:40:11 holtmann: Btw I'm actually fine applying Jessica's patch, it still looks ugly but at least consistent with other parts of the code Jan 18 15:43:01 Then go ahead. Jan 18 15:43:52 The rest of the patch was fine to me. It is just this one situations where enum return and long function name screws it up no matter what. Jan 18 15:44:21 There is nothing we can do about it. And it could well happen the second time I look at that patch, I favor the exact opposite approach ;) Jan 18 15:45:44 denkenz: Or do you want me to go ahead and apply it? Jan 18 15:46:09 I'll take care of it Jan 18 15:46:13 Good. Jan 18 16:00:45 holtmann: I was planning to move the helper function for parsing the retry counter to atuil Jan 18 16:01:38 due to ofono_sim_password_type, i have to include include/modem.h and include/sim.h Jan 18 16:01:44 is it acceptable Jan 18 16:01:52 denkenz: Your call here. Jan 18 16:03:33 are they seriously the same function? Jan 18 16:04:08 If so then including sim.h is fine with me Jan 18 16:04:26 Just the order of PIN counters seems to be different. Jan 18 16:04:30 atleast 2 for loops are exactly the same Jan 18 16:04:32 At least from what I read. Jan 18 16:04:54 why do you need modem.h? Jan 18 16:05:16 except the order in which retries comes and prefix, its almost same Jan 18 16:05:40 i think it was due to compilation issues Jan 18 16:07:01 then yeah send it in Jan 18 16:09:05 or can i move the enum ofono_sim_password_type to types.h Jan 18 16:12:00 *ponders* Jan 18 16:13:07 nah, lets not go there now Jan 18 16:14:26 any specific reason behing not moving it to types.h Jan 18 16:17:19 its still not being used in multiple places or by plugins Jan 18 16:17:41 And even some parts inside types.h now are questionable Jan 18 16:18:29 ok Jan 18 16:20:36 why does the atom IDs enum in ofono.h explicitly assign all the numbers? Jan 18 16:20:57 balrog-k1n: It probably shouldn't Jan 18 16:21:28 And it has a style violation Jan 18 16:21:38 yeah, no tabs :) Jan 18 16:21:48 do i remove the initalisers? Jan 18 16:21:58 yeah Jan 18 16:47:28 denkenz: any comments on the launchbrowser proactive command patch Jan 18 16:55:12 Jeevaka: Nope, sorry I'm a bit behind Jan 18 16:57:30 ok, np Jan 18 17:03:31 padovan: I understand your first comment, but for the second one if I move call to bluetooth_ref() at the end of bluetooth_register_uuid(), it may start bluetooth message exchange even if bluetooth_ref() fails Jan 18 17:06:15 fdanis1: yeah, you right. Jan 18 17:54:20 Im facing a strange issue with recent submit. ofono is not sending AT commands anymore (to phonesim) .... Jan 18 17:56:32 Seems to be related to removing deprecated g_io_channel_write function. Jan 18 17:57:39 Does anybody here got the same behavior ? Jan 18 18:01:15 OlivierG: Yep, holtmann screwed this up Jan 18 18:06:12 ok.. one workaround could be to add a g_io_channel_flush(io->channel, NULL) in the g_at_io_write...but i m not sure about the impacts.... Jan 18 18:11:54 on the surface the patch looks fine Jan 18 18:22:03 Fix pushed Jan 18 18:27:33 denkenz: I did. Hah, stupid GIOChannel buffering :( Jan 18 18:28:07 Yeah, which is why I actually preferred sticking to the deprecated API Jan 18 18:28:19 It has the lowest overhead Jan 18 18:28:43 Maybe I should write GLibLite or something Jan 18 18:29:12 Fair point, but these might go away. Hence the disabling of GLib deprecated symbols. Jan 18 18:31:22 Perhaps, but there's so much voodoo in GAtChat that if you change one line it might have un-intended consequences ;) Jan 18 18:35:59 denkenz: Is there some current user for v.250 in oFono? There is no support for ATD, which I think is the most important command Jan 18 18:48:37 denkenz: I've searched a bit and looks it's just a matter of send ATD*99***1# and then reply with CONNECT. Then we can go to ppp phase. Jan 18 18:49:22 All the other commands are not really needed and the DUN server can just reply OK to them. Jan 18 18:52:06 padovan: v.250 is a base standard for AT commands Jan 18 18:52:23 If you mean whether someone uses those silly S* commands, the answer is no Jan 18 18:57:52 padovan: An I'm pretty sure even ATD*99 is enough Jan 18 18:58:15 ***1 might be too much information even Jan 18 18:58:36 Yeah, I mean the commands in basic_command_register(GAtServer *server) Jan 18 18:58:45 denkenz: Iḿ sure of that now. Jan 18 18:59:23 The only reason we support them is that DUN profile mandates them Jan 18 18:59:37 Maybe the PTS tester actually exercises these Jan 18 19:00:40 Yeah, but we don't need no action for the other commands, just reply OK Jan 18 19:02:59 For some of those yeah Jan 18 19:03:31 holtmann: What do you think of separating the api docs from other docs Jan 18 19:03:50 holtmann: That directory is getting cluttered Jan 18 19:08:25 denkenz: IMO, +1 Jan 18 19:10:42 +1, I agree. Jan 18 19:24:03 denkenz: Any proposals on how? Jan 18 19:24:24 mkdir api, mv doc/*-api.txt api Jan 18 19:24:49 If we do so, we should make sure that this is in sync with all the other projects. Jan 18 19:30:14 Hence I'm asking you :) Jan 18 19:47:58 pessi: ping Jan 18 19:55:12 demarchi: So I'm thinking of renaming CalledLineIdentification in Voicecall to just CalledLine or Line Jan 18 20:34:19 denkenz: then the ATD*99 will also enable the GPRS context in oFono, right? Jan 18 20:34:32 nope Jan 18 20:34:35 Then it will be visible by ConnMan. Jan 18 20:36:12 What's the GPRS role here then? Jan 18 20:36:56 denkenz: what about call-settings? Jan 18 20:37:20 do i send a v3? Jan 18 20:37:23 padovan: For doing basic DUN gprs atom plays no role Jan 18 20:37:40 demarchi: No I made all the changes already, just making sure you're not totally against it Jan 18 20:37:46 I ended up calling it 'IncomingLine' Jan 18 20:38:00 ahn... ok, np Jan 18 20:38:41 denkenz: Crap, I'm getting confused by Zhenhua patches. I was assuming they were partially right. Jan 18 20:40:26 padovan: hah ;) Jan 18 20:42:04 akiniemi: pong? Jan 18 20:43:59 denkenz: Let me think a bit about potential doc directory structure. We might also needs Samuel's and Johan's input here. Jan 18 20:44:24 sure, it might be that oFono is especially bad in this area Jan 18 20:44:35 So we're hitting this issue first Jan 18 20:44:53 Yep. oFono is hitting a lot of issues first since the code base is huge. Jan 18 20:48:15 pessi: never mind, I figured it out already Jan 18 20:49:09 pessi: was about your gisi-notify patches Jan 18 21:10:50 demarchi: Care to send a TODO patch for CDIP as well? Jan 18 21:12:47 denkenz: ok... when i'm back in front of a computer Jan 18 21:19:18 denkenz: "forced-auto" or better "auto-only"? Jan 18 21:25:08 auto-only seems better Jan 18 21:25:24 denkenz: Yeah, I can now have a ppp negotiation ;) Jan 18 21:29:56 sweet Jan 18 21:41:31 denkez, balrog-k1n: any idea how we handle isims? Jan 18 21:42:01 what's an isim? Jan 18 21:42:55 IMS sim application Jan 18 21:43:05 like USIM is 3G SIM application Jan 18 21:43:28 So besides reading some specs, can I get one somewhere? Jan 18 21:44:39 besides reading 31.103, yes, we have ordered some Jan 18 21:45:16 from gemplus I think Jan 18 21:45:19 so my next response is 'gimme?' :) Jan 18 21:46:01 sure, I'll try to get two extra ones for you and andrzej Jan 18 22:10:26 denkenz: is it worth having an uglier api to hide struct ofono_sim_app_record? Jan 18 22:11:30 if we return each record of EFdir separately the core then needs to build the list of all records Jan 18 22:12:03 plus if the driver uses +CUAD it'll need to parse the response anyway to split the long response into records, so it might as well return the parsed data Jan 18 22:13:29 balrog-k1n: Why does it need to parse the response? Jan 18 22:13:30 also if the modem is not an atmodem and returns parsed data then the commands need to reassemble EFdir Jan 18 22:13:49 denkenz: to split the long string of hex into individual dataobjs Jan 18 22:14:19 denkenz: did you forget to push the cdip implementation? Jan 18 22:14:24 i thought it would be something like while (g_at_iresult_iter_next("+CUAD:")) ofono_sim_auth_application(sa, data, len) Jan 18 22:14:54 demarchi: yep, sec Jan 18 22:15:37 demarchi: pushed Jan 18 22:15:53 balrog-k1n: Also, doesn't 27.007 mandate CUAD response per record? Jan 18 22:16:14 it could do that but core would then need to handle a whole list of records in one call Jan 18 22:16:38 or in many calls Jan 18 22:17:11 So here's the problem, I don't really want the different drivers to parse the information Jan 18 22:17:27 The code in there is not trivial and the CRSM implementation would have to be different from CUAD Jan 18 22:17:30 Not to mention ISI Jan 18 22:17:39 It is much easier to do this once in the core Jan 18 22:17:50 exactly Jan 18 22:18:03 i think what you propose is too AT specific if we return the response from +CUAD Jan 18 22:18:15 so it's best to handle the differences in the driver Jan 18 22:18:32 27.007 is what we use Jan 18 22:18:38 So I see it the opposite way Jan 18 22:18:42 27.007 is for AT only Jan 18 22:18:54 But it is the only standard we have Jan 18 22:20:07 the thing is we have no reason to have traces of 27.007 in the core, in voicecall for example we manage to not use it Jan 18 22:20:27 Ok, let us start over Jan 18 22:20:36 What is the format of CUAD response? Jan 18 22:20:50 it's all the records of EFdir concatenated Jan 18 22:21:23 so why do you do: Jan 18 22:21:23 + while (g_at_result_iter_next(&iter, "+CUAD:")) { Jan 18 22:21:52 just in case there are more +CUAD responses as i think i've seen such an example somewhere (can't remember where) Jan 18 22:21:56 can't hurt anyway Jan 18 22:23:02 Ok, so now I understand where you're coming from Jan 18 22:23:18 Since 27.007 is not really clear whether CUAD responds with one line or multiple Jan 18 22:23:21 it would seem more useful if +CUAD was specified that way, Jan 18 22:23:29 but it's not clear, you're right Jan 18 22:24:14 (knowing atmodems, another modem may return pre-parsed data) Jan 18 22:24:29 So let me give you my concerns when I reviewed the code Jan 18 22:24:43 ok, thanks Jan 18 22:24:51 You add +struct ofono_sim_app_record { Jan 18 22:24:53 in types.h Jan 18 22:25:02 The only reason being that you want to include this in simutil.c Jan 18 22:25:23 Personally I see this as belonging in sim-auth.h, but then we can't really use it inside simutil.c Jan 18 22:25:25 it's also used in include/sim-auth.h (primarily) Jan 18 22:25:38 yeah Jan 18 22:25:54 So right there this is flagged as 'different' Jan 18 22:26:02 Since we usually hide such structures inside fooutil.h Jan 18 22:26:41 The second concern I have is the actual parser in the driver, it is fairly sizeable Jan 18 22:26:54 even with the utility function from the core Jan 18 22:27:41 So really I prefer for the core to handle the nasty details here, but it all depends on how we interpret CUAD Jan 18 22:27:41 yeah, although that part is +CUAD specific Jan 18 22:28:31 If CUAD is a concat of all records, then returning a byte array + len to the core seems fine Jan 18 22:28:50 if CUAD is per record, then doing what I proposed in the last reply seems fine Jan 18 22:29:10 The CRSM implementation can simply strcat in the first case Jan 18 22:29:15 or notify in the second case Jan 18 22:30:03 well it'd work Jan 18 22:30:30 but you're kind of letting 27.007 leak into the core by looking at what +CUAD does Jan 18 22:30:46 denkenz: don't you like copying struct without memcpy? Jan 18 22:31:12 demarchi: Old habit and I think that it is more readable / explicit Jan 18 22:31:30 balrog-k1n: What do you mean by 'leaking', we've always based our API on 27.007 Jan 18 22:33:02 denkenz: hmm Jan 18 22:33:32 balrog-k1n: even voicecall is largely based on 27.007 with the chld crap Jan 18 22:33:45 we just add a few extensions because every vendor in the world uses them Jan 18 22:33:55 so do you want ofono_sim_auth_application_notify(sim_auth, data, len) which can be called once or multiple times? Jan 18 22:34:38 This really depends on our interpretation of CUAD Jan 18 22:35:23 Both approaches are fine from my standpoint Jan 18 22:35:27 i think we have to interpret it as unclear, both things can happen Jan 18 22:36:07 Then maybe using phonebook style way is best Jan 18 22:36:28 either way we choose, your driver becomes 10 lines instead of 60 Jan 18 22:37:01 and the respective core code becomes more than 70 :) Jan 18 22:37:17 * balrog-k1n would prefer that the callback is passed as parameter of the call for consistency, btw Jan 18 22:37:34 Sure, but we take the pain in the core to make the other drivers easy Jan 18 22:38:32 I'm fine either way Jan 18 22:38:44 denkenz: i'm looking at phonebook.h and i don't see the difference between the two ways you suggest Jan 18 22:39:19 the idea is that you call a driver method, and driver calls a global function by name once or multiple times as it wishes, right? Jan 18 22:39:45 so typedef void (*ofono_sim_auth_cb_t)(const struct ofono_error *error, Jan 18 22:39:45 const unsigned char *data, int length, void *data); Jan 18 22:39:54 for the case where CUAD returns everything at once Jan 18 22:40:21 or typedef void (*ofono_sim_auth_cb_t)(const struct ofono_error *error, Jan 18 22:40:21 void *data); Jan 18 22:40:26 + the notify function Jan 18 22:40:33 the driver works somewhat like this: Jan 18 22:40:45 while (g_at_result_iter_next("+CUAD:")) { Jan 18 22:40:46 ah ok Jan 18 22:40:47 notify(); Jan 18 22:40:48 } Jan 18 22:40:50 cb() Jan 18 22:41:13 we can just concatenate all the strings in the driver, too Jan 18 22:41:19 yep Jan 18 22:41:40 This comes down to how you interpret this command Jan 18 22:41:57 Likely the SIM comes with like a max of 4-5 records in EFdir Jan 18 22:42:17 So you can easily fit this into 2048 byte response Jan 18 22:42:47 so i propose the this, let's use the former API you suggest (callback and no notify function), and let's handle both cases of +CUAD, it's like 15 lines of code anyway Jan 18 22:43:38 sounds like a plan, I have no preference on the API, just hiding the details of +struct ofono_sim_app_record { Jan 18 22:43:59 ok Jan 18 22:44:14 if 3GPP ever clarifies 27.007, then we can deal with it Jan 18 22:44:43 but then the hardware is out already and we deal with hardware not 27.007 :) Jan 18 22:45:13 Of course, but we have to pick some 'idealized' API Jan 18 22:45:28 The further a manufacturer strays from that, the more pain they have Jan 18 22:45:38 Reminds me that there is an official STK api in 27.007 now Jan 18 22:45:41 hmm good point Jan 18 22:45:41 denkenz: what i know is that gcc generates a better code when we copy structs that way Jan 18 22:45:47 denkenz: at least at O0 Jan 18 22:46:06 but i think in higher levels of optimizations it optimizes both Jan 18 22:46:40 It probably does, I'm fine switching to the 21st century of doing things ;) Jan 18 22:46:49 hahaha Jan 18 22:46:51 But I still find explicit memcpy more clear Jan 18 23:27:35 Hello @all Jan 18 23:27:40 I configured a static 3g modem under /etc/ofono/modem.conf with the test-scripts I can enter a pin but i don't know how to get it 'online' Jan 18 23:28:28 How do I make the GUI (Meego) to offer a 3g option? **** ENDING LOGGING AT Wed Jan 19 02:59:57 2011