Gonk is the lower level operating system of the B2G OS platform, consisting of a Linux kernel based on the Android Open Source Project (AOSP) and userspace hardware abstraction layer (HAL). This article aims to explain what constitutes Gonk; for more on the overall B2G OS architecture and how Gonk fits into this, read our B2G OS architecture guide.
Gonk overview
Gonk is the kernel-level component in the B2G OS stack that serves as the interface between Gecko and the underlying hardware. Gonk controls the underlying hardware and exposes hardware capabilities to Web APIs implemented in Gecko. Gonk can be seen as the “black box” that does all the complex, detailed work behind the scenes to control the mobile device by enacting requests at the hardware level.
Gonk is a simple Linux distribution that includes components from Android (such as GPS and Camera) and is extended by Mozilla with common open-source projects such as libusb, bluez, and so forth to integrate with all layers in the B2G OS architecture. This design makes it easier for OEMs to port software components from other Android implementations (device drivers, firmware, service-level daemons, etc.) for deployment on B2G OS smart phones.
Gonk is a device porting layer: an adapter between the hardware and Gecko. Gonk is a relatively simple Linux distribution that can be treated as a Gecko Port paired with Gecko porting layers — so Gonk is a porting target of Gecko, just like there's a port of Gecko to OS X, Windows, and Android.
Note: Since different mobile devices may have different chipsets and other hardware specs, devices may contain different Gonk distributions.
Since the B2G OS project has full control over Gonk, we can expose interfaces to Gecko that can't be exposed on other operating systems. For example, Gecko has direct access to the full telephony stack and display frame buffer on Gonk.
Gonk architecture
Each mobile phone model has a specialized combination of Gonk components based on the system libraries, device drivers, and firmware required to operate the device. These components are determined by the OEM in collaboration with chipset manufacturers and ODMs. The following figure shows an example Gonk implementation:
This example shows the following main components (which represent only a subset of the possible components in any given Gonk implementation):
- Linux Kernel: Uses libraries from Android (GPS, camera, etc.) and other open source projects (Linux, libusb, bluez, and so on).
- Radio Interface Layer (RIL): Interacts with the modem hardware (telephony) in the phone. Consists of two components:
- rild daemon: Talks to the modem firmware.
- rilProxy: Proxies messages between rild and the b2g process
- mediaserver process: Controls audio and video playback. Gecko communicates with the media server through an Android RPC mechanism.
- netd process: Network daemon that interacts directly with network interfaces (Wi-fi) in the hardware.
- Bluetooth, etc.: Bluetooth and other service-level daemons provide access to hardware capabilities.
Gonk also starts, manages, and shuts down the b2g process, which is the Gecko layer in B2G OS. The b2g process acts as a client to service-level daemons in Gonk that interact directly with the hardware and expose to Gecko the underlying hardware functionality of the phone. Gecko talks with these daemons via inter-process communication (IPC). These components collaboratively exchange commands and protocols to request and provide services.
Note: For more information on Gonk architecture, see the B2G OS architecture guide.
Porting Gonk
Because B2G OS is based on the Android kernel, existing device drivers, firmware, service daemons, and other components can be ported to work with B2G OS, usually with minimal effort. If a custom component (for example, a custom RIL or new daemon) is needed, or if a modification must be made to an ODM’s reference design, then additional integration and testing effort might be required.
In b2g, clients communicate with service-level daemons via inter-process communication (IPC). The client initiates a socket connection to the service-level daemon, submits the request (using the server’s request protocol) over that connection, receives the response, and closes the connection. OEMs are responsible for designing and implementing this inter-process communication between clients and servers.
Note: For more information about how the porting process works, see Porting B2G OS.
How Mozilla works on Gonk ports with OEMs and phone manufacturers
Every Gonk implementation is the result of collaboration among Mozilla, OEMs, and associated manufacturers (ODMs, chipset manufacturers).
Mozilla provides source repositories and support files for Gonk in its B2G OS distributions. The source repositories include the base Linux kernel (with only slight changes) and hooks into Gecko.
OEMs are responsible for building, compiling, testing, certifying, and distributing the B2G OS system image for a given device model. For the Gonk portion of the system image, OEMs are responsible for the bulk of the effort in order to ensure the seamless integration between Web API calls and phone hardware functionality. The type and scope of effort required is highly dependent on the specific chipsets and other hardware components used on the phone.
Device components
OEMs collaborate with chipset manufacturers and ODMs to provide all of the device-specific components that are needed to run the mobile device. For example, a manufacturer of the Wi-Fi components would provide the chipset and affiliated software. Components might include:
- Drivers — For supported phone functionality, such as modem (data and voice), Wi-fi, Bluetooth, display, camera, audio, and so on.
- Firmware — Some hardware (the network interface card, for example) might load firmware off the flash drive.
- Service-level daemons — For invoking and managing the operation of various hardware components. This can include support libraries and startup scripts.
Integration between Gonk and Gecko
OEMs must ensure that hardware capabilities in the mobile device are correctly and completely exposed to the Web APIs implemented in Gecko. This involves:
- building or adapting (in Gonk) service-level daemons, along with any associated drivers or firmware, to manage the hardware functionality
- setting up (in b2g) all the methods needed to communicate with the service-level daemons
Gonk source code
The main B2G repo on Github contains officially supported Gonk ports for a variety of devices, so you can treat it as Gonk’s repository. The list of supported devices is available in B2G/config.sh.
The b2g process (along with other things), defined in Gonk, can be found at mozilla-b2g/gonk-misc. Modifications to b2g source code are made here.
Note: In the Gecko source there’s a b2g/ folder that contains the Gonk Port of Gecko: this consists of a Linux kernel, HAL, and other OEM-specific libraries.
Most of the day to day work done on Gonk work involves porting the system to different boards and make sure Gecko can work well on different devices.