4. Gaia
User interface
application for Firefox
OS devices
Web application running
atop Firefox OS
Comes with some
standard applications
Isolated from Gonk
communicates through
Gecko
5. Gecko
Application run time
Collection of API's for
hardware access
Renders Web Content
ACLs and permissions are
controlled in Gecko
6. Gonk
Linux Kernel
Device Drivers
Hardware Abstraction Layer
Isolated from Gaia
Communicates through Gecko/B2G
Magic Black Box
10. HAL
http://mxr.mozilla.org/mozilla-central/source/hal/
Not exposed directly to JavaScript code
C++ API accessible to higher levels of Gecko
Gecko communicates with Gonk directly
through the HAL
This communication is run in a sandbox
environment
11. init process
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
13. Inter-Process Communication
Inter-process Communication Protocol
Definition Language
Developed by Mozilla
C++ code to pass messages between
processes or threads in a secure way
Apps communicate with service-level
daemons via IPC
16. Hardware Access
Apps access hardware only via Web APIs
Gecko is the sole gateway to mobile device
No “native” API no other “back doors”
Apps are ran in a sandboxed mode
19. 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
20. 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
21. 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
22. 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
between actors
23. 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
24. Licensing Issues
OEMs must sign licensing agreements with
component suppliers
Why?
Due to proprietary components (drivers etc)
specific to that hardware device
25. Who is responsible for Gonk
Mozilla
Maintains source repositories and support files
Repositories include the base Linux kernel
and hooks into Gecko
Maintained under the Mozilla Public License
https://www.mozilla.org/MPL/
26. Third Parties and Gonk
OEMs and ODMs
Building, compiling, testing, certifying,
distributing Firefox OS device images
Ensuring seamless Gonk to Web API (Gecko)
integration calls
Device hardware functionality
27. 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
28. 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
29. 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...
https://developer.mozilla.org/en-
US/Firefox_OS/Installing_on_a_mobile_device
30. 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
repo B2G/config.sh
If yours is not there add it?
31. How to contribute
The b2g process is defined in Gonk
Modifications to b2g source code can be made
https://github.com/mozilla-b2g/gonk-misc
33. 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
Editor's Notes
Little introduction to me
My name is Aimee Maree Forsstrom
Been using Linux since Debian Potato
Contributed to various OSS Web projects
Mentor Children and have taught Python, Scratch, Alice, PHP, HTML/CSS, JavaScript and iOS
Contributed to Meego and learnt QT which lead me onto FireFoxOS
Recently was working with Mozilla in the Mobile Support Team
I have built mobile applications for FireFoxOS, iOS, Android and Windows Phone
Alot of my day to day work is within the mobile web architecture space and my main hobbie and passion is embedded Linux
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
The main layers are what I like to call the “Three Gs”
And under those layers is the device itself
These layers represent the full FireFoxOS Architecture stack
When you write an application for FireFoxOS you do so using web technologies HTML5, CSS and Javascript
the application sits at Gaia level and accesses lower levels through Gecko so just like iOS and WindowsPhone the applications are contained (sandboxed) within the top level where app developers place calls to lower levels through middleware
From a security perspective each application runs it its own sandboxed environment
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
Gecko holds the Web APIs that are used for communication between the upper level of Gaia and the lower level of Gonk
Gecko is the "application runtime" of Firefox OS and Implements the open standards for HTML, CSS, and JS
Gecko is the middleware code which is composed by (among others)
• a networking stack
• graphics stack (which delegates operations to the GPU when needed)
• layout engine (for rendering HTML content)
• virtual machine (for running Javascript code)
• porting layers for various different platforms which live inside the B2G folder of the source code
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
Now that we have had an overview of Gonk lets explain some other components
Within Gonk sits the hardware abstraction layer which is one of the porting layers of Gecko. It handles low-level access to system interfaces across multiple platforms using a C++ API that's accessible to the higher levels of Gecko.
The API is implementation of the HAL is generally modified depending on the needs of the device
This hardware abstraction layer is not exposed directly to JavaScript code in Gecko for security reasons
The sandbox implementation simply proxies requests made by content processes and forwards them to the "Gecko server" process. The proxy requests are sent using IPDL which will discuss later
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's a port of Gecko to Gonk, just like there'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'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'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'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