Hi, The example I considered is just what you said - NFC. Even NFC modules can be dynamically loaded into DRAM (giving the chance for saving DRAM), we still can't save the physical storage space (NAND or eMMC). Any unnecessary modules/codes removed from binary can give End User more spaces for installing their applications without external SD Card.
Sincerely yours. ----- 原始郵件 ----- 寄件者: "Andreas Gal" <[email protected]> 收件者: "Marco Chen" <[email protected]> 副本: "Vicamo Yang" <[email protected]>, [email protected], "Dimi Lee" <[email protected]>, "Garner Lee" <[email protected]>, "Michael Wu" <[email protected]> 寄件備份: 2013 12 月 2 星期一 下午 3:36:33 主旨: Re: [b2g] Per device Gecko configure options Lets discuss which modules you want to remove and how we want to do that. For example, we should not load the NFC module/worker if the device is not NFC capable. I am pretty sure we can do that at runtime in a way that doesn't have a memory overhead. What other modules are you considering? Avoiding loading unnecessary code is always great, so we should do this as a general optimization everywhere. Andreas On Dec 1, 2013, at 9:56 PM, Marco Chen <[email protected]> wrote: > Hi, > > For Tarako, we are considering to remove some modules for saving the space. > So is this not a right direction based on Andreas's comment? > > Thanks, > Sincerely yours. > ----- 原始郵件 ----- > 寄件者: "Andreas Gal" <[email protected]> > 收件者: "Vicamo Yang" <[email protected]> > 副本: [email protected], "Marco Chen" <[email protected]>, > "Dimi Lee" <[email protected]>, "Garner Lee" <[email protected]>, "Michael > Wu" <[email protected]> > 寄件備份: 2013 12 月 2 星期一 下午 1:45:20 > 主旨: Re: [b2g] Per device Gecko configure options > > > For security updates its critical to not develop a diverging zoo of Gecko > binaries. Originally we had one binary that was bit-for-bit identical on all > devices. We at some point reduced that constraint to binary-identical for all > devices with the same gonk version (ICS vs JB etc). Anything beyond that > should be detected by reading props the OEM can set. Please don't further > fork Gecko on a per-device basis. It would dramatically worsen our security > story. > > Thanks, > > Andreas > > On Dec 1, 2013, at 9:15 PM, Vicamo Yang <[email protected]> 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
