**** BEGIN LOGGING AT Thu Apr 22 02:59:57 2010 Apr 22 04:40:34 denkenz: we have both add_state_watch (sim) and add_status_watch (netreg). which one is right, state or status? ;-) Apr 22 04:46:09 i suggest to unify them Apr 22 08:09:25 denkenz: about GIsiClient, its design decision was to avoid heap allocation per request Apr 22 08:09:49 denkenz: not that that couldn't be changed Apr 22 08:10:21 denkenz: if I had to choose between sharing a socket/GIsiClient per atom and a "slimmer" GIsiClient, I'd go for latter Apr 22 08:11:02 denkenz: perhaps that is what I'll do, actually... Need to add a couple of features there -- might as well rewrite while at it ;-) Apr 22 08:28:05 akiniemi: Btw. you don't need to keep gisi/*.[ch] if you don't want to. Apr 22 08:28:20 If it reduces the code, you could integrate it native into isimodem/ Apr 22 08:29:49 akiniemi: And one socket per ISI service should be enough. If you have broken firmware in the modem, then that is okay to workaround, but if you are concerned about resource usage then lets at least avoid some of these sockets. Apr 22 09:15:29 holtmann: I think gisi/ is fine as it is. I'm still thinking gisi could be someday useful as a shared library. Apr 22 09:16:26 holtmann: and yeah, it's not only resource usage, but I'm a bit concerned we have so many atoms doing reachability checks on the same server simultaneously. Apr 22 10:29:11 is'nt that GIsiModem because we have to cast it as void * in core calls? Apr 22 10:44:59 pessi: if the API has an unsigned, then we'd cast that as void *, I guess Apr 22 10:45:34 pessi: or define a struct with a single member and malloc/free that... Apr 22 10:48:46 pessi: but this GIsiClient sharing might change the way we probe the drivers Apr 22 10:49:10 pessi: instead of giving each driver the modem index, we give them a GIsiClient instance Apr 22 10:49:35 shared client? Apr 22 10:49:56 pessi: yeah, per ISI service Apr 22 10:50:09 now we have a GPhonetNetlink instance per isimodem Apr 22 10:50:11 pessi: e.g., gprs and gprs-context share one Apr 22 10:50:16 we could give that instead of GIsiModem Apr 22 10:50:29 pessi: hmm... Apr 22 10:51:08 and even have one socket in for everything in GPhonetNetlink/GisiModem Apr 22 10:51:27 pessi: we thought about that with Rémi a while back Apr 22 10:51:29 and then clients per resource Apr 22 10:51:39 well, think again ;) Apr 22 10:51:45 pessi: problem is then the trid space and msg id space is shared Apr 22 10:52:04 huh? Apr 22 10:52:27 pessi: and we might get an IND conflicting with a RESP between services Apr 22 10:53:02 pessi: not sure how likely this is a problem IRL, though Apr 22 10:53:17 pessi: but sockets are "cheap", or so we thought ;) Apr 22 10:53:20 dispqatch them first by the resource id Apr 22 10:54:13 do all inds have 0 as transaction id? Apr 22 10:55:02 pessi: not sure Apr 22 10:55:57 but if that was so, then it would be easy to just avoid sending reqs with trid 0 Apr 22 10:56:09 maybe this is a good idea after all... Apr 22 10:56:14 yes Apr 22 11:03:13 ..speaking about good ideas, what would be nice name for the flight mode property? Apr 22 11:03:44 "Online" (if its false, then modem is in flight mode?) Apr 22 11:03:51 boolean "FlightMode"? Apr 22 11:05:14 although Online looks nicer alongside Powered Apr 22 11:07:47 pessi: or maybe even a tristate string: (Online, Offline, ModemIsToast) Apr 22 11:08:08 * akiniemi removes tongue from cheek Apr 22 11:10:25 pessi: I propose we do the GIsiClient changes in stages Apr 22 11:10:41 pessi: first share clients per ISI service Apr 22 11:10:54 then enable sharing a socket across all clients Apr 22 11:11:02 sounds like a plan Apr 22 11:23:24 and should we have separate methods in modem driver for 1) asking online/offline (like enable/disable) 2) updating online/offline (like pre_sim/post_sim) Apr 22 11:29:35 pessi: you mean modem ops for online and offline, and notify for online state? Apr 22 11:35:16 yep, like, driver interface for setproperty("Online") and then after driver notifies core of the current state, should core notify driver, too? Apr 22 11:35:44 like set_powered(t) is notified (pre_sim) Apr 22 11:37:55 pessi: ah, yeah that sounds right. The drivers could initially just map flight mode to pre_sim Apr 22 11:38:08 pessi: wasn't that basically what denkenz was suggesting? Apr 22 11:39:36 I try to figure out what he suggested Apr 22 11:42:03 remove atoms on flight mode? Apr 22 11:42:30 send events online offline to watches? Apr 22 11:47:48 ok, I think he just wanted to have oneline/offline watch Apr 22 12:26:55 hmm... GIsiClient dispatches indications vs. responses based on fd Apr 22 12:28:39 so there's already a pair of sockets per client Apr 22 13:56:51 pessi: I suggested having FlightMode property of some kind and another level for pre_sim/post_sim for atoms that are available with a sim but not the network Apr 22 13:57:31 Today we can make that list into e.g. phonebook to start, and go from there Apr 22 14:02:41 so we would have three atom lists, like, pre_sim, flight, post_sim? Apr 22 14:03:00 that's what I'm proposing yes Apr 22 14:03:04 and post_sim atoms would be flushed when going to flight mode? Apr 22 14:03:11 correct Apr 22 14:03:18 post_sim might need to be renamed Apr 22 14:03:33 pre_sim, post_sim, online? Apr 22 14:03:44 pre_sim, flight, online? Apr 22 14:04:45 so far I like pre_sim, post_sim, online Apr 22 14:49:21 and how the modem kwown which atoms insert into which list? Apr 22 14:50:12 by atom type? Apr 22 14:54:34 right now it is based on phase Apr 22 14:56:06 you can do something similar, e.g. pin entered and in flight mode -> populate post sim, otherwise populate both Apr 22 14:56:51 ok, I'll have to check how the existing drivers do it.. Apr 22 14:57:29 and btw, do you have any suggestions for nice atmodem for testing ofono? Apr 22 14:57:40 phonesim? :) Apr 22 14:58:09 Personally I do initial testing on it since its bloody fast Apr 22 14:58:30 However, MBM modems (F3507/F3607) are the most compliant Apr 22 14:58:39 HSO ones don't allow SIM reading Apr 22 15:03:03 thanks Apr 22 15:32:51 denkenz: I quick followup on my previous Phonet/ISI question... I spent some time reading through the Symbian sources... the good news is that it shares many common parts with the N900 interface, but the main part (the access to the SIM) is different , i.e. N900 uses a PN_SIM resource while Symbian uses a PN_UICC... probably due to different modem HW Apr 22 15:34:12 this means that I should wait for some more contributions from Nokian's (hopefully due to meego) before continuing playing with ofono code + N900 ... Apr 22 15:34:42 lizardo: I know that the Nokia folks said they don't have direct access to the SIM Apr 22 15:34:56 lizardo: So you'd really need to ask them or wait for them to contribute Apr 22 15:39:47 denkenz: yes, the ISI interface presents a "high level" interface that is quite different (and less powerful) from e.g. the AT one... but based on what csd and sscd processes do on N900, I believe it is quite feasible to have ofono replacing them some time in future ... Except for SIM Toolkit , whose support on N900 is zero Apr 22 16:38:39 lizardo: pekka is working on exactly that, i.e., an n900 plugin that replaces sscd Apr 22 16:39:27 lizardo: we welcome patches for PN_UICC support Apr 22 16:39:43 I'm sure it'll come handy one of these days ;) Apr 22 16:49:20 how should we expose SMS dialects in the SMSManager API? Apr 22 16:49:44 For sending? Apr 22 16:49:46 a new Alphabet property [readwrite], or SendWithDialect() method, or something else? Apr 22 16:49:50 denkenz: yes Apr 22 16:50:03 Yuck, I thought we decided not to do that? Apr 22 16:50:14 denkenz: eventually, it's a must have... Apr 22 16:50:41 I'd vote for the property Apr 22 16:51:02 Can this be in a config file? Or is this an actual user property? Apr 22 16:52:52 Probably the config file needs to specify a default Apr 22 16:53:07 But I'd like it to be possible to change at run-time... Apr 22 16:53:12 No, my question is whether you guys envision the user changing this Apr 22 16:53:38 If you do, then I agree that a property is the better way Apr 22 16:54:30 That's actually really hard to say. Regulators might argue it shall not be possible. Apr 22 16:54:41 But then that property can always be made readonly. Apr 22 16:55:00 No, if it is locked to the phone, then simply make it a config option Apr 22 16:55:04 e.g. /etc/ofono/main.conf Apr 22 16:55:40 You can always implement it as a main.conf property and change it later Apr 22 16:55:51 Conservative way first... Apr 22 16:55:56 I'm actually thinking of adding a new dialect... Apr 22 16:56:19 ...current phones have this "reduced" alphabet that it seems some regions just love Apr 22 16:56:32 Reduced alphabet is bullshit Apr 22 16:56:41 It is basically a lossy conversion Apr 22 16:56:49 I know Apr 22 16:56:57 They use the default GSM charset, and not a dialect Apr 22 16:57:14 Without naming any names, some operators swear by it. I think we need it. Apr 22 16:57:34 And it is a dialect of sorts, as you Apr 22 16:57:53 There are no headers, hence its not a dialect Apr 22 16:58:01 However, I know what you're saying Apr 22 16:58:02 're basically just defining encoding conversion dialect, but use Apr 22 16:58:16 the default alphabet on-the-wire Apr 22 16:58:41 So I was thinking to add it in as a pseudo dialect, for encoding Apr 22 16:59:21 So then the "Alphabet" property could have default, reduced, turkish, spanish, portuguese... Apr 22 16:59:35 and the rest, dozen or so values :) Apr 22 16:59:58 Again, my preference it to start with a main.conf setting Apr 22 17:00:11 If you actually want it as a user setting we can always add the property Apr 22 17:00:39 However, I knew this was coming, so I'm actually fine with your proposal Apr 22 17:01:11 Perhaps we make the main.conf switch override as default, and make the property a readonly one? Apr 22 17:02:56 why do you want the property? For UI purposes? Apr 22 17:03:28 Yes Apr 22 17:03:58 In that case make it a readwrite property and the security framework can take care of protecting it Apr 22 17:07:18 akiniemi: unfortunately I don't have any HW that uses PN_UICC (well, at least one where I can put ofono into) , I was most interested on helping on N900 stuff, but it uses PN_SIM, which symbian code does not support :( Apr 22 17:07:58 lizardo: we're painfully aware of that Apr 22 17:08:36 it sucks, really. We've done some ugly reverse-abstraction klugery in the SIM driver just to make at least some things work (SPN, etc) Apr 22 17:13:02 akiniemi: and what is worse, I am interested mostly in the SIM Toolkit support which after some time studying the sscd/csd binaries I can it does not support :( (but for someone willing to add PN_UICC support, everything needed is there on symbian code) Apr 22 17:14:11 lizardo: STK is partly done on the modem firmware on the N900, actually. That's why you didn't see any traces of it. :) Apr 22 17:14:52 lizardo: we've got PN_UICC documentation available, too. Probably at some point we'll have someone freed up to add support. Apr 22 17:15:23 Probably not in the near term, though. Apr 22 17:15:36 That is anyway the sanest API wrt oFono. Apr 22 17:16:37 akiniemi: what I meant is that I couldn't get any traces of the possible message IDs and service types from those binaries because well... they don't use it :) and having no traces of the interface makes it very difficult to do something... Apr 22 17:17:51 akiniemi: for PN_UICC there is even both source code (symbian) and some documentation (http://www.wirelessmodemapi.com/) available, but nothing about PN_SIM Apr 22 17:19:39 lizardo: PN_SIM is legacy stuff Apr 22 17:20:34 akiniemi: yes... but I couldn't get N900 to talk to PN_UICC with the modem FW that comes with it... Apr 22 17:21:27 lizardo: that's because it doesn't have PN_UICC Apr 22 17:23:36 akiniemi: what I imagined :) I even did a sort of poor's man resource ID discovery application using g_isi_client_create() and g_isi_verify() and printing the versions... and PN_UICC was not there Apr 22 17:24:00 lizardo: cool! Apr 22 17:24:37 I could find at least 28 reachable resource IDs... no idea what most of them are though :) Apr 22 17:25:07 by the symbian code I can guess some are for testing Apr 22 17:25:48 lizardo: you should know there's also a firewall in the firmware that blocks stuff that the N900 images aren't using... Apr 22 17:26:54 akiniemi: "strings" on the CMT MCU firware file gave that hint... I could see a couple of those firewall messages Apr 22 17:27:57 well that was the far as I could go... I'll sure wait for you guys to provide more docs (or even code) so I can proceed :) Apr 22 17:31:18 for anyone interested, that was the output of my "ISI resource ID discovery" tool on a N900: http://pastebin.com/MR7gAakd (some show version as "-1" probably due to some firewall block) Apr 22 17:50:30 lizardo: the -1 versions are because some services report garbage. Likely if the firewall blocked the request, it was silently ignored, i.e. timeout. Apr 22 17:50:52 I need to add an error code for GIsiClient for when the FW blocks the request. Apr 22 17:54:54 akiniemi: does it return anything or just drops the requests ? Apr 22 17:55:33 It returns something, but probably GIsiClient doesn't know how to match that with any pending requests. **** ENDING LOGGING AT Fri Apr 23 02:59:56 2010