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
