By now you would of heard about FireFoxOS from Mozila It has been in the wild now for just over a year First started life as the B2G project aka Boot 2 Gecko It is still reffered to as B2G in github repos and documentation on the web It is Mozillas attempt at entering the mobile platform space It is aimed at lower end smart phones but this is not a limiting factor it just means that a main ideal is to allow it to run with a small memory footprint It is built using Open Web Standards and as such you can deploy and maintain your own apps without the need for distribution through the Mozilla MarketPlace
So at the top we have Gaia which is the web application running atop of Gecko Comes with a standard stack of applications, phone caller, messaging app, contacts, calendar etc When you roll your own firefoxos Gaia will include the basic stack of common applications (phone dialler, calendar, messaging, marketplace and some others) and then you can apply various other applications at that level for your device Gaia communicates to Gonk through Gecko
Gonk is the name given to the layer that holds the Linux Kernel, Device Drivers and the Firmware needed to communicate directly within the device It is a lower level operating system of the Firefox OS platform, consisting of a Linux kernel (based on the Android Open Source Project (AOSP)) and userspace hardware abstraction layer (HAL). It is isolated from the higher levels and communicates in the userspace through the gecko layer and Web APIs It’s the core component that is adapted for differing chipsets and device hardware features, and one could say it is largely chipset-specific which we will speak more about later.
Looking into some of the components of the Gonk layer we can see; The Radio Interface Layer (RIL) which interacts with the modem hardware in the phone. It consists of two components: rild daemon talks to the modem firmware rilProxy proxies messages between rild and the b2g process There is a mediaserver which controls audio and video playback. Gecko communicates with the media server through an Android RPC mechanism. Also netd process akak the Network daemon that interacts directly with hardware network interfaces Bluetooth and other service-level daemons providing access to hardware capabilities. These are common modules obviously there are others that can and will sit at this level Linux Kernel distro uses libraries from Android (GPS, camera, etc.) and other open source projects Linux, libusb, bluez, to name a few. Then we have the Firmware and drivers at the lowest level
So as we have discussed Gaia speaks to Gecko A single request from Gecko can trigger a complex series of operations, initiated and managed by Gonk, in the device. In this example, the Radio Interface Layer (RIL) in Gonk is responsible for controlling the modem hardware that will dial the requested number. The b2g process communicates the dial request to the rilProxy, which forwards the request onto the rild service-level daemon. The rild controls the actual modem hardware via the Linux kernel and any associated modem firmware and drivers. The rild sets up the modem and causes it to dial the number. Any changes in the modem state (dialing, ringing, busy, connecting, connected, disconnecting, disconnected, or incoming) are reported via the b2g process up the Firefox OS stack.
As mentioned Gaia is where the application will live The app communicates to Gecko through the execution environment who in turn talks to the permissions manager who is the only access the Web APIS to the underlying hardware. who checks through ACLs what can/can not be done [ Matrix of roles and permissions required to access Web API functionality.] Credential Validation: Authentication of apps/users. Permissions Store: Set of privileges required to access Web API functionality. Once confirmed it then communicates through Web APIs who talk to boot to Gecko It is then at this point that communication with Gonk is initiated Gonk will then communicate directly to the hardware device
The Firefox OS init.rc is basically stock Android with patches to include things required to kick-start Firefox OS, therefore can vary from device to device depending on the needs. The init process in Gonk also handles mounting required file systems and spawns system services. After init is ran, a userspace init process is launched. Once the init process is launched, the Linux kernel handles system calls from userspace, and interrupts from the hardware. After that, it stays around to serve as a process manage which is similar to other UNIX-like operating systems.
Execution begins in the primary bootloader From there, a succession of increasingly higher-level bootloaders bootstrap the next loader in the chain. the general system bootup flow goes from bootloaders in the Kernel space, to init in the native code, to B2G and then Gecko in the user space, and then finally to the system app, window manager, then the homescreen app inside Gecko. This is what all other apps are then executed on top of.
Inter process communication is handled by IPDL which was developed by Mozilla and is used across various projects not just FirefoxOS All IPDL messages are sent between parent and child end points, called actors. An IPDL protocol declares how actors communicate: it declares the possible messages that are sent between actors, and a state machine describing when messages are allowed to be sent.
In FirefoxOS we have a Multi-process Architecture This means each app is ran in a different process allowing it to run with the least amount of privileges. As you can see there is a single parent process called b2g. The b2g process has a child process called nuwa, you can think of nuwa as the main child process which is then forked everytime an app is started As mentioned the default is that child processes are run with the minimal set of privileges. When higher privileges are needed they need to go through the parent process (b2g). This is where Inter-process Communication (IPC) comes into place. Each child has an IPC channel, to the parent which will be used for its communication.
So if your familiar with using Unix sockets then this system will not seem unfamilar, FireFoxOS uses Unix sockets created with the socketpair system call, to send messages across the process boundary. The system calls sendmsg and recvmsg Each process has its own dedicated thread that handles the socket operations, this is called an IOLoop. Each IOLoop thread has its own outgoing message queue, which is used by the main thread to send a new message across the channel. All IPDL messages are sent between parent and a child end points, aka actors. An IPDL protocol declares how actors communicate: it declares the possible messages that may be sent and a state machine describing when messages are allowed to be sent.
Web apps have only one entry point to access mobile phone functionality which are the Firefox OS Web APIs, which are implemented in Gecko. This means Gecko provides the sole gateway to the mobile device and underlying services. The only way to access device hardware functionality is to make a Web API call through Gecko There is no “native” API and there are no other routes so no “back doors” to bypass this mechanism and interact directly with the hardware or access low-level software layer.
So we can see from this diagram that sandboxes use IPC as the trust boundary for communications to the parent process. Each app aka child process communicates to the parent process using this trust boundary. Firefox OS and Linux desktop Firefox use the same implementation of sandboxing
Ok so now lets take another look at all the layers together We can see the gecko parent / child relationship stated at the higher levels and note how communication to the lower levels need to go through the permissions manager to gain access to lower levels all of which lives in the Gecko layer Hopefully by this time in the talk the layers of FirefoxOS and the need for separation is starting to make sense? Now that we have covered the layers and there communication process lets look into the Linux Kernel and some of the components utilized.
Gonk consists of a very small linux kernel that borrows a lot from ASOP as it is effectively an android derived kernel IT is a very basic kernel and does not use all parts of ASOP and also contains certain parts that are Mozilla specific to ensure the boot to gecko process The kernel and several of the user space libraries are common open-source projects: Linux, libusb, bluez, OpenGLES... Some of the other parts of the HAL are shared with the AOSP: GPS and the camera for example. You could say that Gonk is a very simple Linux distribution with a focus on small memory footprint
Ok so basically we can explain Gonk now in one sentence... Gonk is a porting target of Gecko; That is, there&apos;s a port of Gecko to Gonk, just like there&apos;s a port of Gecko to OS X, Windows, and Android. Since the Firefox OS project has full control over Gonk, we can expose interfaces to Gecko that can&apos;t be exposed on other operating systems. An example, Gecko has direct access to the full telephony stack and display frame buffer on Gonk, but doesn&apos;t have this access on any other operating system what I mean here is that the port of Gecko for Windows for example does not have nor requires this access.
As well as having a Linux Kernel in Gonk which is covered under the Mozilla Public License there are also components that relate to the specific device the OS is being ran on The OEM drivers and firmware are largely proprietary and relate to the device itself and are not held to the same license schedule as the Gonk Kernel itself It is important to re-iterate at this point that the bootstrapping process within OEM devices is highly device-specific and therefore may and can and more then likely will be proprietary.
So we have discussed certain aspects of the FireFox OS Architecture and also certain components of Gonk we should take a look at what is the process when people/companies need to make changes to Gonk When specific functionality is required in Gonk this needs to be added by the ODM/OEM/Company/human aka you This means that the GONK will need to be extended and the HAL files modified to expose new functionality for access to specific device functions/requirements And an important part of this process is designing and implementing the interprocess communication between layers on the device
In order to integrate the lower levels in Gonk to Gaia through to Gecko after you have exposed the new functionality in Gonk you need to modify the Gecko Source code to extend the Web APIs to expose the new functionality An important part of this is designing the inter-process communication so new functions can work inbetween the areas on the stack
Licensing issues.... well not really issues per say as in how Mozilla handles proprietary code OEMs must sign licensing agreements with component suppliers to ensure that all code/drivers /firmware being used is allowed to be used etc as this talk does not dive deep into licensing I dont think we should go to much more deeper into the topic then this... but lets have a quick look at who is responsible for what in Gonk
As discussed GONK is really a derived version of Android OS with some Mozillian touches Due to this Mozilla maintains the source repositories and any needed support files It is maintained as an Open Source project under the Mozilla Public License, Therefore the project can be forked/cloned etc The upstream process is not as straight forward as one might like it to be this is due to the fact that there are also third party components that will not be included in the Mozilla repos As with Android it is at the discretion of Mozilla what it wishes to accept into the Mozilla lets say raw Gonk and you could say Mozilla tries to maintain a vanilla Gonk distro to make it easy for people to add/extend
The land of mobile devices can sometimes be a tricky one to mitigate due to device chipsets etc This sees other third parties responsible for components within Gonk aka the needed drivers/firmware for the specific hardware of the device they are releasing with FireFoxOS At this level the changes and drivers created do not need to be upstreamed and companies can effectively add their own drivers without the need to push up to Mozilla or out to the general public Therefore it falls to Third Parties device owners to maintain their own build and ensure seamless communications with Gonk and Gecko
The good thing about FireFoxOS is that you can simply flash your phone and get the latest updates There is various documentation on the Mozilla Developer pages on how to flash your device as it is an android derivative it requires the same build tools that needed to flash android devices You can flash your device with the standard Mozilla FireFoxOS images apart from that Companies can also make there images available for you to flash at this point in time I believe that only GeeksPhone are supporting their own images as well as APC though APC is not for a phone device but is a port for a small pc device
Most of the work that people contribute to has been to get FireFoxOS running across different devices The list of supported deevices can be found in the github repository at B2G/config.sh If you want to roll it onto a device that is not listed you can start working on it in your own time to add the device At the moment Mozilla Developer devices are the Flame and Geeksphone iterations apart from this you can install the FireFoxOS simulator which runs inside of FireFox Browser and is also integrated into Mozillas new Browser IDEz
The source files for FireFoxOS is kept on github The actual build process starts with obtaining a copy of the Firefox OS (or B2G) software, usually by creating a Git clone of the B2G project. The build configuration will both obtain copies of all the source code which is to be built and create the .config file that specifies variables for the build. You can also look in bugzilla for bugs to squash All bugs are handled through BugZilla as with all Mozilla projects Most of the day to day work done on Gonk involves porting the system to different boards and make sure Gecko can work well on different devices. There are weekly call ups on Mozilla Air most of these are contained to mozillians paid and volunteers so not so open to the everyday public
So it is important to remember that FireFoxOS has been out for about a year now so it is still a relative baby on the market There have been some exciting news come out which has seen it move from just mobile phones to other so called portable devices Panasonic announced a partnership with Mozilla to use FireFoxOS to support smart Tv&apos;s The APC team developed the paper and rock mini/portable PCs they maintain there port of FireFoxOS for the device on github There is also a FireFoxOS tablet that is being worked on though no specific release dates Mozilla has also announced a ChromeCast competitor There is also a flash for Raspberry Pi Lost of new projects are coming out regularly
FirefoxOS and its use of Linux (a deep dive into Gonk architecture)
FireFoxOS and its use of Linux
Aimee Maree Forsstrom
What is FireFoxOS
by Mozilla to
C++ API accessible to higher levels of Gecko
Gecko communicates with Gonk directly
through the HAL
This communication is run in a sandbox
Will execute processes defined in init.rc and
the successor init.b2g.rc
Launches userspace init process
Once the init process is launched, Linux kernel
handles system calls from userspace, and
interrupts from hardware device
Hardware features are exposed to
userspace through sysfs
Inter-process Communication Protocol
Developed by Mozilla
C++ code to pass messages between
processes or threads in a secure way
Apps communicate with service-level
daemons via IPC
So what parts of the kernel?
Derived from Android (ASOP)
Uses libraries from Android (GPS, camera)
Has extra Mozilla components
These changes to ASOP are not upstreamed
unique to FireFoxOS project
Very basic Linux Kernel
libusb, bluez and others OSS libraries
Basically, Gonk is a port of Gecko
Gonk is a porting target of Gecko for FireFoxOS
Gecko has full control over Gonk
Difference in the exposure of interfaces
Two examples telephony stack and display
frame buffer where Gonk has full access
This is not the same for FireFox Browser
Linux Kernel and OEMs
Devices will have OEM drivers and firmware to
address specific device hardware needs
Vendors can modify the kernel and upstream
those changes on their own schedule
OEM's can also create device drivers and
firmware which are not upstreamed
Implementing changes in GONK
Due to unique nature of mobile devices
custom components may/will be required
Gonk can be extended in HAL and init and
additional firmware/drivers added
Anything added in HAL etc will need to have
an inter-process communication channel
Integrating with Gecko
You might expose hardware functionality not
currently accessible via Web APIs in Gecko
You first expose functionality in Gonk then you
modify Gecko Source to extend the Web APIs
This allows access to the functionality required
by the service-level daemon
OEMs must sign licensing agreements with
Due to proprietary components (drivers etc)
specific to that hardware device
Who is responsible for Gonk
Maintains source repositories and support files
Repositories include the base Linux kernel
and hooks into Gecko
Maintained under the Mozilla Public License
Third Parties and Gonk
OEMs and ODMs
Building, compiling, testing, certifying,
distributing Firefox OS device images
Ensuring seamless Gonk to Web API (Gecko)
Device hardware functionality
So the blockers, you say?
Upstream process is not guaranteed
There is proprietary drivers that will never see
the light of the upstream
Fragmentation starts to occur
Each OEM, Device owner, person can
maintain their own fork of FireFoxOS
Always limitations :/
Good example: mobile phones
It's up to the telcos to push out an upgrade
1.1 is the main version in the wild yet Mozilla
is at version 2 already :/
Hard to provide community support
Frustrating to users they can see upgrades
discussed online but not on their phone
Makes you want to...
Flash your own device and maintain your own
phone distro to stay ahead
Annoying maybe? But hey at least with
FireFoxOS you can if you so choose...
Make it your own
Based on Android kernel (ASOP)
This (hopefully) makes it easier to port existing
device drivers, firmware, service daemons,
and other components
Supported devices list can be found in the
If yours is not there add it?
How to contribute
The b2g process is defined in Gonk
Modifications to b2g source code can be made
So more Mobile Platforms?
Choice is Good
Being a Monopoly is bad for all
Linux was made for embedded devices
Go forth and play with FireFoxOS
Roll your own distro with the Yocto Project
Check out Tizen