**** BEGIN LOGGING AT Thu Feb 10 02:59:57 2011 Feb 10 15:17:21 OlivierG: ping Feb 10 16:50:18 denkenz: hi Feb 10 16:52:34 leiyu: heya Feb 10 16:52:49 have question about general ofono design consideration. Feb 10 16:53:01 about "atom->pending" usage. Feb 10 16:53:52 I see in quite a few cases in ofono, "atom->pending" is used and ofono will return "BUSY" error if that atom is busy serving one request when another request is coming in. Feb 10 16:54:31 With that logic, that means upper layer SW modules will have to handle the "BUSY" case and re-try later. Feb 10 16:55:16 yes? Feb 10 16:55:31 I am not very comfortable with that design since it adds a lot of extra overhead to upper layer which i feel should be handled transparently by ofono. Feb 10 16:56:05 Like to know your thoughts especially if this has been discussed before. Feb 10 16:56:14 sounds nice on paper, but in practice it is not workable Feb 10 16:56:37 You mean not workable for ofono to handle that? Feb 10 16:56:52 correct Feb 10 16:57:13 The internal driver design pretty much assumes 1 outstanding driver command can be issued at once Feb 10 16:57:15 because that will imply that ofono will maintain extensive state machine to see which request is valid? Feb 10 16:57:27 And we're not doing request queueing inside the core Feb 10 16:57:33 For that, ofono should just queue the request. Feb 10 16:57:43 no, all pointless Feb 10 16:58:09 Why pointless since you don't see use case or need, or you feel not much trouble to upper layer? Feb 10 16:58:29 all of the above Feb 10 16:59:10 Then, the implicit rule is that user of ofono will need to handle BUSY error return and re-try? Feb 10 16:59:38 The implicit rule is that if you're getting a busy error you're doing something wrong Feb 10 16:59:55 No, that can't be the assumption. Feb 10 17:00:13 For example, what if two applications both want to use "get_properties"? Feb 10 17:00:38 With a few exceptions GetProperties is not marked async and executes immediately Feb 10 17:00:46 so you won't get a busy anyway Feb 10 17:01:15 Yes, I am talking about "exceptions", i.e., ofono is not sticking with one way all the time. Feb 10 17:01:19 I find the design simple and puts the logic where it belongs IMHO Feb 10 17:01:33 For example, sms's get_property. Feb 10 17:02:17 I understand it makes ofono simple but will make upper layer harder to make good usage of ofono. Even worse, ofono is not handling this the same way cross the board and also the "If busy, pls retry" is a hidden rule, not spelled out anywhere. Feb 10 17:02:54 sms_get_property should probably be re-arranged to return sync if the cached flag is set Feb 10 17:02:55 Since that decision is not clear to ofono developer nor clear to external (in api.txt), I can see confusion will arise. Feb 10 17:03:14 If you're unlucky that you perform the SCA request at the same time as another process, then you're SOL Feb 10 17:03:22 You need to handle that possibility Feb 10 17:03:56 The likelyhood of this is obviously almost nil Feb 10 17:03:58 But, if ofono queue the request, then upper layer does not need to deal with that possibility. Feb 10 17:04:16 For that likelyhood, I would really disagree. Feb 10 17:04:17 As I said, been there, done that, no ;) Feb 10 17:04:43 Also, from my past experience, the most scary part is device/system starup. Feb 10 17:05:14 where every application tries to read in some values and store in their local memory (of course, register for value change indication). Feb 10 17:05:32 During that period of time, a lot of simulatenous query will happen. Feb 10 17:05:44 If you're making apps that intersect domains, then you're doing something wrong Feb 10 17:06:25 as I said, there are probably bugs in the present code where the busy error can be optimized Feb 10 17:06:35 But as a general design decision I do not want queuing Feb 10 17:07:03 My design preference is this: Feb 10 17:07:45 a). If operations should not happen at the same time, e.g. network->register and network-scan, then return busy is definitely Ok. Feb 10 17:07:57 b). otherwise, we should allow simulatenous operation. Feb 10 17:08:10 That includes get_property. Feb 10 17:08:26 And we agree there Feb 10 17:08:35 As I said, the SMS get_properties today is a bug Feb 10 17:08:45 it should return sync if cached flag is set Feb 10 17:09:17 Then, if it is not cached, it will return BUSY error if another one is coming in? Feb 10 17:10:15 that will be wrong too since it is not case a) above and should be treated as case b). Feb 10 17:11:38 If two apps try to query at the same time, one has to win Feb 10 17:11:50 The other one will get a busy and has to wait for the property signal to be emitted Feb 10 17:12:41 Again, I don't feel that is a nice server, which ofono is, behavior. Feb 10 17:12:58 Shrug, I don't think you will ever encounter this in practice Feb 10 17:13:16 There's no reason for anyone to use GetProperties on the SMS atom besides the settings app Feb 10 17:14:09 Again, seen in the past, been nightmare. Ok, we can hold of this thread for a minute or a while. Feb 10 17:14:12 oFono is separated into logical domains for exactly that reason Feb 10 17:14:36 It minimizes contention Feb 10 17:14:44 Another thing you bring up: if an application cross domain then, there is something wrong with that application. Feb 10 17:14:49 If you have clients that will have this, you have to take care of it Feb 10 17:14:59 this--> cross domain? Feb 10 17:15:16 yes Feb 10 17:16:02 But, in open application development environment, there will be no co-ordination possible between clients. Feb 10 17:16:37 Through platform API (e.g., Qt or anything), any developer can write their application to use any API, at any combinations, as long as it conforms to documented rules. Feb 10 17:16:44 leiyu: We have eliminated the race conditions where multiple clients access the same data. For example inside the modem interface. Feb 10 17:17:04 And for all the rest you will have one application per domain. I don't expect anything else. Feb 10 17:17:38 As I said, in real systems you won't have this contention Feb 10 17:17:40 Also keep in mind that in a real system there will be an extensive security model behind it. Which will prevent access to certain settings unless you are privileged. Feb 10 17:17:40 But what about 3rd party developer, i.e., the developers would write some apps to get paid? :-) Feb 10 17:17:44 If you do then you're doing something wrong Feb 10 17:18:07 On a generalized desktop, sure Feb 10 17:18:09 3rd party apps will most likely not have access to any settings. That is up to the settings app alone. Feb 10 17:18:16 But then you can easily write the app to avoid it Feb 10 17:18:25 Or simply back off and wait for the property changed Feb 10 17:19:09 I can agree on "write" to settings but read should be mostly free to any app. Again, mixing security vs. contention is not a good idea, IMHO. Feb 10 17:19:36 Even on today's smart phone, more and more APIs are available to 3rd party developer. Feb 10 17:19:37 reading from cache is nearly always instantaneous Feb 10 17:19:57 If you need to bootstrap the cache, and you have multiple pending requests, one is SOL Feb 10 17:20:00 reading from cache is sure a way out, i.e., remove async. Feb 10 17:20:03 Give me an example on what settings you wanna read or write. Feb 10 17:20:21 Your own phone number, Feb 10 17:20:28 only read. Feb 10 17:20:30 of course. Feb 10 17:20:47 Again, who cares besides the settings app? Feb 10 17:20:55 And that is the one where I do not want every 3rd party app being able to do so. Feb 10 17:21:16 It is a security issue if a 3rd party app can read you phone number without you confirming it. Feb 10 17:21:34 Not to mention that EFmsisdn can be bogus anyway Feb 10 17:21:44 That one is pure informational purpose Feb 10 17:21:57 And really only useful if you plan to take your SIM out Feb 10 17:22:08 Probably you are right from security concern but I am not feeling good not having general contention resolving rules but rely on security restrictions. Feb 10 17:22:59 What I try to convey is that I would like to see a general contention resolving design and rule. Feb 10 17:23:07 leiyu: do you have a real problem with this? or is this purely theoretical? Feb 10 17:23:36 I do have real problem with this, depending on your definition of "real". :-) Feb 10 17:23:50 The general rule is: Avoid contention in the first place Feb 10 17:23:59 We are designing APIs one layer above ofono for CDMA extension. Feb 10 17:24:15 If you for some reason can't (which I don't buy ;) then simply use a back-off strategy Feb 10 17:24:21 We encounter this issue where whether that upper API layer should queue the request in case of BUSY or what. Feb 10 17:24:23 e.g. ebusy -> wait for property changed Feb 10 17:24:56 leiyu: IMHO upper layer deals with this, it's not too much to ask for. Feb 10 17:25:28 Ok, at least I know it is not oversight in ofono from design decision perspective. Feb 10 17:25:32 leiyu: do you deal with EAGAIN and EINTR in your low-level C programs, don't you? (and I hope you know what I'm talking here :-) Feb 10 17:26:31 leiyu: well, it's not oversight. holtmann and denkenz have a lot of experience with this. we need to optimize for the common case and not add queue handling which will rarely be used and only add unnecessary bloat (and bugs) Feb 10 17:26:39 I know, but I doubt those things are dealt with by UI application which expects lower layer (middleware and etc) will queue and handle it nicely. Feb 10 17:27:21 Trust me, been there, it won't work out 'nicely' Feb 10 17:27:50 UI shouldn't expect that, period. if busy, try again. simple, right? and if you do have a real problem, we can always discuss it. Feb 10 17:27:51 Thanks. I will take it as design decision and move from here, and hope everything will work out 'nicely'. :-) Feb 10 17:28:22 Besides, oFono API is not really made to have 'frameworks' be put on top of Feb 10 17:28:36 Its pretty much already organized into domains Feb 10 17:28:51 You can stick some language bindings on it, ala ofono-qt Feb 10 17:29:02 But if you're doing something more, I question its value Feb 10 17:29:11 yes, ofono-qt is something I am in mind Feb 10 17:29:34 Not any expensive framework. Feb 10 17:29:42 ok, good Feb 10 17:29:52 No plan to have CDMA framework. ;-) Feb 10 17:30:23 ofono is doing great. it's evolving based on real use cases and with simplicity in mind. that's really good. Feb 10 17:32:30 BTW, I did not see anywhere the "BUSY" return is documented for any api.txt, for low-level C API, EAGAIN and etc are well documented so that user of the API can prepare to handle those. Feb 10 17:32:37 Did I miss info again? Feb 10 17:32:52 Our docs are not always up to date with respect to errors Feb 10 17:32:56 So that is a problem Feb 10 17:33:01 Got it. Feb 10 17:33:02 Patches are welcome. We might have missed some. Feb 10 17:33:23 If you see it missing, point it out, or better just send a patch for it. Feb 10 17:33:23 Sure, I can try to see if we have bandwidth to do that. :-) Feb 10 17:33:51 Denis and I are almost API blind on these since we looked at these files way too much. Feb 10 17:34:16 and I pushed a fix to have sms return asap if it is cached Feb 10 17:34:31 leiyu: thanks. if you see it while developing on top of ofono, please just drop us an e-mail or even a patch to docs. Feb 10 17:34:37 if you notice any other optimizations with ebusy we can make, feel free to point them out Feb 10 17:36:27 sure. thanks. Feb 10 19:23:45 denkenz: Just posted a patch for a crash related to a bluetoothd crash. I'm going to fix the bluetoothd crash so if you want to know more details why this happens you have to ask me fast ;) Feb 10 19:25:17 what about a fix for the oFono crash? Then I won't have to ask ;) Feb 10 19:27:26 That is what I meant. I sended a patch for the ofono crash Feb 10 19:27:34 but I can't really tell what's happening in bluez Feb 10 19:27:47 the deamon crashes when I try to enable the modem Feb 10 19:27:55 this results in a ofono crash Feb 10 19:28:07 with the patch I send ofono stays around Feb 10 19:28:19 but as I said I don't know exactly what's wrong Feb 10 19:28:32 only derefencing a NULL pointer is a bad idea Feb 10 19:28:41 strange Feb 10 19:28:53 But as I said, that code has not had any maintenance in a while Feb 10 19:28:58 Probably on the BlueZ side as well Feb 10 19:29:23 Or it could be the latest changes from fdanis / padovan Feb 10 19:29:49 okay, I'm trying to get it working for me Feb 10 19:30:00 the good news is that appart of the audio Feb 10 19:30:05 the rest works very good Feb 10 19:30:29 wagi: where is the patch that fixes the crash? Feb 10 19:30:32 the only thing which isn't good yet is, after I terminat the call on the phone side Feb 10 19:30:40 then I have to set the modem online again Feb 10 19:30:47 but that is for latere Feb 10 19:31:15 padovan: let me check. maybe I misspeled the mail addresss ;) Feb 10 19:33:52 modem online or powered? Feb 10 19:34:19 The phone might be closing the rfcomm connection Feb 10 19:35:33 * wagi is still looking where the mail is Feb 10 19:36:11 I received the e-mail now Feb 10 19:36:29 ahhh Feb 10 19:37:07 hah, so your bluetoothd crashes Feb 10 19:37:12 hfp removes all the modems Feb 10 19:37:16 And then a reply comes back Feb 10 19:37:52 cool, you figured whats wrong then? Feb 10 19:38:36 padovan: btw, does HFP work for you? I'm not sure if I just have the luck of bad hardware Feb 10 19:39:02 why bluez crashes no Feb 10 19:39:13 wagi: I don't. I haven't tried it in months. Feb 10 19:39:16 But your fix might actually be accessing a modem object that has ceased to exist Feb 10 19:39:30 might try running it through valgrind Feb 10 19:39:52 padovan: right. I'll need it very soon to be working. There are some very high interest in this Feb 10 19:40:03 But people reported to me that a disconnection issue with pulseaudio. Feb 10 19:40:17 wagi: what doesn't work for you? Feb 10 19:40:47 we probably need to simply return from that function if you get a No service error Feb 10 19:40:50 padovan: following symptons: I start with test-voicecall Feb 10 19:41:09 padovan: apart of the audio data all seems to work fine Feb 10 19:41:20 padovan: PulseAudio gets its FD Feb 10 19:41:31 padovan: and tells me everything is fine (start to roll) Feb 10 19:41:46 padovan: and after 5 seconds the idle timeout kicks in Feb 10 19:42:04 padovan: and terminates the connection, sending BT_STREAM_STOP Feb 10 19:42:16 padovan: and the phone stops the SCO connections Feb 10 19:42:33 padovan: If I comment the stream stop code, the phone keeps on sending SCO messages Feb 10 19:43:08 padovan: hcidump tells me that there is data going from our userspace to the device and vise versa Feb 10 19:43:28 padovan: I tried to figure where things go wrong but I can't tell. I got lost in PA :) Feb 10 19:44:14 You're not the only one Feb 10 19:44:19 Could be similar to the issue that someone reported to me. Feb 10 19:44:43 I have no clue about pulseaudio. It wasn't me that wrote the pulseaudio part. ;) Feb 10 19:44:53 I'll give a try to it now. Feb 10 19:44:59 cool, thanks! Feb 10 19:45:01 wagi: sounds like jhe is your man Feb 10 19:45:18 denkenz: yeah, I'll go over to bluez and bother Johan a bit ;) Feb 10 19:45:18 If bluez crashes, its likely in the audio subsystem Feb 10 19:45:44 funny thing is, at work I have almost the same setup, but no crash Feb 10 19:45:49 probable timing Feb 10 19:46:30 could be, the oFono side is pretty simple Feb 10 19:46:43 There might be some weird situations like the one you had, where bluez crashes Feb 10 19:46:50 But afterward it should be smooth sailing Feb 10 19:47:11 denkenz: about the crash: No service? Feb 10 19:47:41 yeah, basically we remove the modem objects, even though there are pending calls over D-Bus with the modem object as the userdata Feb 10 19:47:53 eventually the pending call returns with e.g. no service Feb 10 19:48:00 but the modem object is already gone Feb 10 19:48:21 so we probably have to take care of that, but then bluez shouldn't crash either ;) Feb 10 19:48:38 I completely agree ;) Feb 10 19:55:25 denkenz: the pending calls are 'stored' in dbus-daemon, or are already 'owned' by ofono? Feb 10 19:55:50 * wagi enjoys a good beer Feb 10 19:56:02 pending calls are in libdbus Feb 10 19:56:22 So when a message arrives from the d-bus daemon, libdbus fires the pending call callback Feb 10 19:56:43 unfortunately we don't track the pending calls and cancel them when we detect the modem has gone bye bye Feb 10 19:56:46 right, so we have to steal them from libdbus when we remove the modems. just learned that there is dbus_pending_call_steal_reply :) Feb 10 19:57:03 dbus_pending_call_cancel is probably what you want Feb 10 19:57:08 But yeah, basically Feb 10 20:00:53 wagi: nothing happens in pulseaudio to me. It doesn't detect the new stream, I don't know why. Feb 10 20:01:11 padovan: start pulseaudio with --log-level=4 Feb 10 20:01:21 is that the same as -vvv? Feb 10 20:01:30 yeah, just on 'v' more Feb 10 20:01:43 I thinkg -vvvv is the same as --log-level=4 Feb 10 20:01:49 which means debug Feb 10 20:02:38 In my logs I see at one point the line "Stream properly set up, we're ready to roll!" Feb 10 20:03:03 that's from pulseaudio/src/modules/bluetooth/module-bluetooth-device.c Feb 10 20:03:26 the function start_stream_fd retries from bluez the FD Feb 10 20:04:06 Nothing :( Feb 10 20:04:09 If you look into ipc.h in the same directory you see a sequence diagram Feb 10 20:04:22 so you should see what should happen in theory ;) Feb 10 20:05:45 http://pastebin.com/DYSR9ALn Feb 10 20:08:36 mine stops here: luetoothd[2546]: audio/main.c:sco_server_cb() Accepted SCO connection from 00:22:A5:00:5A:25 Feb 10 20:09:10 okay, that one I have too. that's when the device starts to send SCO data Feb 10 20:10:15 denkenz: I'll add the reply cancel to my TODO list, I just want to proceed with the debugging session. Hope that's okay ;) Feb 10 20:10:25 no prob Feb 10 20:18:13 the good news is if I get HFP working, chances are good that I can get another developer working on this topic. So you see where my motivation is coming from ;) Feb 10 20:20:21 see, I don't even have bluez setup on my vm Feb 10 20:20:24 Much less Pulse :P Feb 10 20:21:06 I just recently talked to Lennart. Now I know at least who is ressponsible for PA :) Feb 10 20:21:31 yes, not sure exactly what you mean, but an emphatic yes anyway ;) Feb 10 20:21:50 hehe Feb 10 20:23:19 wooo, bluez crashes because of SELINUX Feb 10 20:23:29 now that is nice Feb 10 20:23:56 Funny crash. Feb 10 20:26:16 at least I have the same behavior as with my other setup **** ENDING LOGGING AT Fri Feb 11 02:59:57 2011