On Dec 1, 2013, at 11:58 PM, Marco Chen <[email protected]> wrote: > 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.
How much space do the compressed NFC modules occupy in flash relative to other components? I don't think NFC would provide any realistic savings here. For very large components this is a valid argument. I don't think NFC is such a component. Again, there is a really big security benefit from having one version of Gecko. If there are very strong arguments to diverge from that, lets discuss it. I haven't heard any such strong arguments yet, so lets list anything else you want to optimize. Thanks, Andreas > > 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
