Hi, In my opinion, we shouldn't allow for enabling/disabling arbitrary components on our development phones, otherwise we'll end up with tons of different combinations. And the resource savings are probably not worth it.
Using runtime detection of available features seems much cleaner. if there are race conditions between the detection code and something else, we should fix them instead. We had this discussion for NFC, and I think it would be perfectly fine to handle NFC detection completely within the NFC daemon. If NFC is not available on the device, the NFC daemon would just do nothing (and maybe reply with error message to Gecko). The same might be doable for RIL. Best regards Thomas On 02.12.2013 06:15, Vicamo Yang wrote: > Hi all, > > Recently we have a few bugs regarding the variety of features of > different devices/platforms. See bug 920551 [1] and bug 939056 [2]. > The problem is: shall we allow --disable-foo in per device configuration? > > Right now we have a file named 'default-gecko-config' inside gonk-misc/. > The file contains 23 default |ac_add_options ...| lines and several of > them are further controlled by environment variables exported in > '.config' and/or '.userconfig'. > > Besides, there is also another way to inject such compile time options. > The 'Android.mk' file in same gonk-misk/ directory suggests one may > assign "GECKO_CONFIGURE_ARGS" in any other "Android.mk" files, and the > value will be passed as "CONFIGURE_ARGS" env variable to Gecko during > the configure stage. The best home for this variable is per device > 'BoardConfig.mk' for sure. > > So back to the original problem: shall we allow --disable-foo in per > device configuration? That is: shall we allow assigning > "GECKO_CONFIGURE_ARGS" in per device 'BoardConfig.mk'? > > I would say YES. My 2 cents: > > 1) Code size. > > Back to bug 864485 [3], migrating Telephony IPC from frame messaging to > IPDL, Telephony DOM code was then built on ALL platforms just like what > we have for MobileMessage. By ALL, I mean it's compiled even on > Windows. Then I got a regression mail saying the built binary size grew > 1% after that patch on platforms didn't have WebTelephony before. Taking > current /system/lib/libxul.so for example, 1% means 230KB. I heard > there is some kind of delayed loading tech in use, but this still comes > to my mind first when we were to built-in some dead code in final > executables. > > 2) Runtime detection may lead to a certain problem. > > The two bugs, 920551 and 939056, are for enabling/disabling a certain > B2G feature(s) on different devices. These features come with DOM APIs > for sure. For now we're to hide APIs from user content when it's not > available. Runtime detection is suggested but it takes time. It > follows the first call to retrieve the availability of such feature > should only be made after we're fully confident/determined there is no > such feature on that device. For example, FTU need to know whether does > the device implement RIL APIs or not before it's to display a menu item > for "Import SIM contacts". Such calls have to be delayed after runtime > detection is done, and again these detections take some time. Why not > just skip these detections on devices that have no such feature at all? > > 3) How and why > > Till now, all devices have their own Gecko binaries. They're built > directly from the source code and each of them is basically different > from each other. No any devices share Gecko binaries at the time at > all. Some devices have even additional patches to Gecko applied, and > some replaces built-in components with their own. Mozilla just can't > stop device makers from compiling Gecko by their own. And we just > shouldn't do so, either. The thing we should only care is to provide > unified Web API interfaces to users, not binary monopoly to device makers. > > So, what would you say? > > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=920551 > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=939056 > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=864485 > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
