FirefoxOS and its use of Linux (a deep dive into Gonk architecture)
•Als ODP, PDF herunterladen•
10 gefällt mir•9,905 views
Talk given at LinuxCon America in Chicago 2014 about FireFoxOS and its use of Linux Kernel
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie FirefoxOS and its use of Linux (a deep dive into Gonk architecture)
Ähnlich wie FirefoxOS and its use of Linux (a deep dive into Gonk architecture) (20)
Mehr von Aimee Maree Forsstrom
Mehr von Aimee Maree Forsstrom (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
FirefoxOS and its use of Linux (a deep dive into Gonk architecture)
- 1. FireFoxOS and its use of Linux Aimee Maree Forsstrom mozillians.org/en-US/u/aimeemaree aimeemaree.info @aimee_maree
- 2. What is FireFoxOS Mobile Operating System developed by Mozilla to power mobile devices Utilises Linux, Android and Gecko (FireFox browser engine)
- 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
- 7. Lets dive deeper into Gonk
- 8. How Gonk handles a request
- 9. How the layers communicate
- 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
- 12. BootStrap
- 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
- 14. IPC Architecture
- 15. IPC Parent <> Child relationship
- 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
- 18. Lets take another look
- 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
- 32. Cool toys and future projects
- 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
Hinweis der Redaktion
- 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 &quot;application runtime&quot; 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&apos;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 &quot;Gecko server&quot; 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&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