From HTML5 to Hardware - Simonyi Conference Budapest April 15

From HTML5 to hardware
@janjongboom
Simonyi Conference, Budapest, April 15
Tuesday, April 15, 14

@janjongboom
I’m Jan, live in Amsterdam. Work for Telenor on Mozilla products. Firefox OS contributor & keyboard peer. I write code for Gaia
and Gecko.

Internet is normal for western world, but big part of the world doesnt have it.
Click Only 2.5 billion people out of 7.

4,500,000,000
Internet is normal for western world, but big part of the world doesnt have it.
Click Only 2.5 billion people out of 7.

The web has everything
Information does not like to be locked down
We want people to access the web, not the closed silo’s that Android / iOS are, because thats not where the information is

Affordable device to access the
internet
So goal: affordable device that people can use to get on the internet

Meet Firefox OS

19,000 HUF
First generation came out last year. Goes for about 19000 HUF here in Hungary (65 eur)

Next generation is going to be lower. System requirements are four times as low as Android.

Great performance on cheap
hardware?
So if we want to get great performance out of cheap hardware, how do we do it?

Traditional model: Application -> VM (f.e. Dalvik on Android; .NET on Windows Phone, JavaScript in V8)

Dalvik .NET V8

Dalvik .NET V8
Apps Apps Apps

Most mobile OS’es
App
VM on top of OS. Kernel is hardware dependent. But always two layers between App and Kernel.

Most mobile OS’es
App VM

Most mobile OS’es
App VM OS

Most mobile OS’es
App VM OS Kernel

Most mobile OS’es
App VM OS Kernel Hardware

Firefox OS
App
JS VM
Browser
Kernel Hardware
Firefox OS only has one intermediate layer. The browser. Everything has to go through there. No exceptions like proprietary APIs
(ok, well a few)

One application runtime
Browser runs directly on top of the kernel
So browser directly on top of the kernel. No overhead.

Everything runs in browser
SMS, Payments, Marketplace
System itself can’t take shortcuts. Everything is browser. Also system apps.

Small Kernel
• Small Linux kernel
• Based on Android Open Source Project
• Contains Hardware Abstraction Layer
• Porting target
• Boot straight into Gecko
All runs on top of a very small kernel. Based on Android OSP. Contains HAL and boots straight into Gecko. Gecko is browser
engine.

Windows
Makes it easier and light weight. Windows: 998 lines of calls to Win32 API on clipboard code.

Firefox OS
Firefox OS: 200 lines, just have a var that holds the clipboard. Other stuff is IPC.

Application runtime
Application runtime is done through iframes. Every application is iframe.

Window Manager
• Boot into HTML app (system)
• System is the window manager
• Applications are loaded in iframe
• iframes can be ran out of process
The window manager is called the system app. It creates the iframes on demand. There is automatic process isolation in place.
For example Here maps.

remote=true
It’s an iframe that points to a special URL that maps to a location on disk. But it has remote=true.

Automatic process isolation, and automatic user isolation. Security ftw.

Tracing down a SMS message
From HTML to the RIL
All cool, but now let’s talk about some actual code. How does it look like if you make a call from HTML to the RIL.

I NEED AN ADULT!
No clue what the RIL is? I’ll walk you through it.

We’ll walk over what happens if you click Send, up until the moment it reaches the cell tower.

Gaia
Gecko
Gonk
User Interface
Browser engine
Kernel
FFOS consists of three layers. Gaia, Gecko, Gonk

Gaia
• Frontend
• github.com/mozilla-b2g/gaia
• All system applications
• HTML/CSS/JS
• SMS app code under /apps/sms
(that easy!)
Gaia, open source frontend. Not limited to only run on Gecko (but at the moment it is).

index.html
SMS app index.html has the button

thread_ui.js
Button has click handler that goes to MessageManager. There is also a callback involved.

message_manager.js
MessageManager makes a call to Gecko (under navigator object). Returns a DOMRequest. Like a promise.

message_manager.js
Gecko!
MessageManager makes a call to Gecko (under navigator object). Returns a DOMRequest. Like a promise.

We need to go deeper!
So let’s go into Gecko.

Gecko
• Browser engine
• Same as Firefox for Desktop / Android / etc.
• Runs directly on kernel (B2G)
Browser engine

nsIDOMMobileMessageManager.idl
(yeah, that’s long)
Gecko has IDL ﬁles. These are shared by browser vendors so eveyrone implements the same API. Can be implemented in C++ or
JSM (variant of JS)

nsIDOMMobileMessageManager.idl
(yeah, that’s long)
addEventListener
Gecko has IDL ﬁles. These are shared by browser vendors so eveyrone implements the same API. Can be implemented in C++ or
JSM (variant of JS)

MobileMessageManager.cpp
Could also be .jsm
Inheritance chain. This is written in CPP.

JS values get boxed automatically. We create a new DOMRequest. See the gaia code.

Then in the same function we make a call to the SMS Service. This is platform speciﬁc. Android does different than FFOS.

Services are platform speci!c
Then in the same function we make a call to the SMS Service. This is platform speciﬁc. Android does different than FFOS.

moz.build
Service injection at compile time
This is the service injection in moz.build. Happens at compile time. In android we need Android SMS database access. FFOS we
don’t.

Time to go DEEPER

Gonk
• Kernel
• Hardware Abstraction
• Think of the clipboard example
• Android code calls back to Android
• We can go straight to the RIL
Gonk is the kernel. If you have platform dependent code it’s not in Gecko but in Gonk. Target for Gecko.

SmsService.cpp
Get the radio interface layer. It’s the API to the chipset in the phone. And send SMS.

dom/system folder
There are a bunch of platforms, they implement the services. In this case the RIL service is implemented by Gonk.

nsIRadioInterfaceLayer.idl
Also has IDL deﬁnitions.

RadioInterfaceLayer.js
Could also be .cpp
RIL code has been written in javascript in this case. It does stuff like normalizing phone numbers, because the chipset won’t do
that for you

RadioInterfaceLayer.js
Now dispatch to a worker. JS single-threaded. Can’t wait for the response from hardware. Response codes are RIL data. Use these
to feed back into the DOMRequest.

rilMessageToken is used to get the callbacks.

Something in between to shake up the audience.

ril_worker.js
Now ril_worker talks to the actual hardware. Pretty simple stuff. Some options.

Mindig írni
byte az én RIL!
I always write bytes to the RIL. RIL doesn’t understand JS or CPP. Only understands bytes.

ril_worker.js
So now depending on protocol we talk, we dump bytes. SEND_SMS is 25, then some options. Send the parcel and now it’s on the
actual RIL.

Radio Interface Layer
• Proprietary
• Comes with chipset
• Trade secret
• Delivered to RIL? Done!
• See how it looks like?
https://github.com/mozilla-b2g/b2g/
And that’s where our job is done. RIL is proprietary and comes with chipset. RIL calls back with the token, we bubble it up back
to Gecko and eventually Gaia, and show user the feedback. This happens in under a second. There is ref implementtion from
Mozilla if you want to look at it.

OMGAWESOME
Play around? I have devices with me.
OMG AWESOME SHIT. All open source. I have some devices, including the 25$ phone with me.

Thank you!
slideshare.net/janjongboom
Thanks!

slideshare.net/janjongboom
Questions?
Thanks!

From HTML5 to Hardware - Simonyi Conference Budapest April 15

Recommended

Recommended

More Related Content

What's hot

What's hot (10)

Similar to From HTML5 to Hardware - Simonyi Conference Budapest April 15

Similar to From HTML5 to Hardware - Simonyi Conference Budapest April 15 (20)

More from Jan Jongboom

More from Jan Jongboom (20)

Recently uploaded

Recently uploaded (20)

From HTML5 to Hardware - Simonyi Conference Budapest April 15