Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Per device Gecko configure options

77 views
Skip to first unread message

Vicamo Yang

unread,
Dec 2, 2013, 12:15:09 AM12/2/13
to mozilla...@lists.mozilla.org, Marco Chen, Dimi Lee, Garner Lee, Michael Wu
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

Andreas Gal

unread,
Dec 2, 2013, 12:45:20 AM12/2/13
to Vicamo Yang, Marco Chen, mozilla...@lists.mozilla.org, Dimi Lee, Garner Lee, Michael Wu

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
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

Marco Chen

unread,
Dec 2, 2013, 12:56:38 AM12/2/13
to Andreas Gal, Vicamo Yang, mozilla...@lists.mozilla.org, Dimi Lee, Garner Lee, Michael Wu
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" <andre...@gmail.com>
收件者: "Vicamo Yang" <vic...@gmail.com>
副本: mozilla...@lists.mozilla.org, "Marco Chen" <mc...@mozilla.com>, "Dimi Lee" <dl...@mozilla.com>, "Garner Lee" <dgarn...@gmail.com>, "Michael Wu" <m...@mozilla.com>
寄件備份: 2013 12 月 2 星期一 下午 1:45:20
主旨: Re: [b2g] Per device Gecko configure options

Andreas Gal

unread,
Dec 2, 2013, 2:36:33 AM12/2/13
to Marco Chen, Vicamo Yang, mozilla...@lists.mozilla.org, Dimi Lee, Garner Lee, Michael Wu

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

Marco Chen

unread,
Dec 2, 2013, 2:58:23 AM12/2/13
to Andreas Gal, Vicamo Yang, mozilla...@lists.mozilla.org, Dimi Lee, Garner Lee, Michael Wu
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" <andre...@gmail.com>
收件者: "Marco Chen" <mc...@mozilla.com>
副本: "Vicamo Yang" <vic...@gmail.com>, mozilla...@lists.mozilla.org, "Dimi Lee" <dl...@mozilla.com>, "Garner Lee" <dgarn...@gmail.com>, "Michael Wu" <m...@mozilla.com>
寄件備份: 2013 12 月 2 星期一 下午 3:36:33

Andreas Gal

unread,
Dec 2, 2013, 3:29:33 AM12/2/13
to Marco Chen, Vicamo Yang, mozilla...@lists.mozilla.org, Dimi Lee, Garner Lee, Michael Wu

On Dec 1, 2013, at 11:58 PM, Marco Chen <mc...@mozilla.com> 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

Thomas Zimmermann

unread,
Dec 2, 2013, 5:20:36 AM12/2/13
to Vicamo Yang, Marco Chen, mozilla...@lists.mozilla.org, Dimi Lee, Garner Lee, Michael Wu
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

Garner Lee

unread,
Dec 2, 2013, 2:32:43 PM12/2/13
to Thomas Zimmermann, Vicamo Yang, Marco Chen, mozilla...@lists.mozilla.org, Dimi Lee, Michael Wu
I also posted the question on the *Bug
939056,*<https://bugzilla.mozilla.org/show_bug.cgi?id=939056>If NFC
function is disabled at runtime, should the navigator.mozNfc object
also NOT exist, or should it be there, but with methods behaving as no-ops?

As for not worrying about storage usage, I agree it might not matter much
in practice. Storage is getting quite plentiful on smartphones, and a few
kilobytes isn't going to be missed as soon as the user snaps a single 8
Mpix picture at normal compression.

-Garner


On Mon, Dec 2, 2013 at 2:20 AM, Thomas Zimmermann
<tzimm...@mozilla.com>wrote:

Tim Chien

unread,
Feb 9, 2014, 8:46:11 AM2/9/14
to Andreas Gal, Michael Wu, Marco Chen, mozilla...@lists.mozilla.org, Vicamo Yang, Dimi Lee, Garner Lee
Hi,

First, I would like to know if this opinion apply to Gaia or not.
There are various build config to modify resulting Gaia packages, and
keyboard app already include layouts (which is JavaScript) and
dictionary files selectively based on config given. With multiple form
factors on the horizon, there will certainly be more creative build
steps added to fit our needs.

Second, I don't understand how we are going to keep this security
practice valid as an OS vendor. OEM and partners (e.g. QC) will
certainly modify Gecko to fit their needs. We are making Gecko more
secure in any way if we only tie our hands but allow partners to do
whatever they want.


On Mon, Dec 2, 2013 at 1:45 PM, Andreas Gal <andre...@gmail.com> wrote:
>
> 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
>
--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

fk

unread,
Feb 23, 2014, 7:44:37 PM2/23/14
to
On Monday, 2 December 2013 06:45:20 UTC+1, Andreas Gal wrote:
> 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.

So how does that work for different CPU types? I'm currently trying to port B2G to the HTC Wildfire which has an armv6 CPU. As far as I can see, the Gecko config happily ignores that and tries to compile for armv7. Even if that build would finish (it fails at some linking right now), the resulting binary would just not run on the device. What's the recommended approach in this case?

Regards, Felix
0 new messages