The Fuchsia is bright (pink)!
Tam Hanna’s career saw him use a wide variety of embedded operating systems. Let him guide you through a quick look at Google’s new OS.
Google is building an all-new open source operating system with a kernel that’s not Linux-based. Tam Hanna explains why it’s not quite time to panic, yet.
Having a background in the aerospace industry helps with understanding other market trends: much of the recent operating system development can be analogised by looking at the TU-334 and MD-9X aircraft series. Both of them fizzled out at the end of their relative career, as they were overtaken by rivals based on more modern airfoils. Operating systems face a similar situation. Standards such as POSIX might have tamed the wild growth of UNIX platforms in the past, but has since become both benefit and curse. For example, implementing POSIX in its entity on a small microcontroller is not particularly entertaining. It, furthermore, has consequences on latencies which can be catastrophic. At the start of my development career, microcontrollers were slow and cumbersome. Dedicated real-time operating system vendors made a killing with products such as FREERTOS or Threadx – they offered extremely stringent latency demands, but had little in terms of GUI or network stacks.
In the past, embedded designers used combinatorial process computers not dissimilar to the Arduino Yun. A classic desktop operating system handled user interaction, while a real-time core managed system control. The miracle of semiconductor engineering ensured that microcontroller performance increases steadily. Present-day STM32 controllers can outrun 20-year-old workstation, for instance.
Google’s Fuchsia is, in some way, the natural continuation of this trend. Based on cutting-edge research in theoretical informatics, the operating system is intended to be as efficient as possible while still offering developers a wide range of APIS and services. Recent developments help this trend: developers have, by and large, forgone C++ for higher-level languages which are interpreted at run time.
Linux is, in principle, a highly reliable operating system – but it does also have some weaknesses of its own. Firstly, the GPL licence is not to everyone’s liking; the realities of the market show that keeping your source code secret can lead to significant benefits in many scenarios. Fuchsia avoids this problem – most of the operating system is under a three-clause BSD licence, while the Littlekernel used as the base of Zircon is Mit-licensed.
Problem number two stems from the development of computer hardware: Linux got started on 32-bit microprocessors with next to nothing in terms of graphics acceleration. Fuchsia’s kernel is strictly 64-bit, while the graphics uses Vulkan. This, incidentally, is why support for the Raspberry Pi 3 was dropped last year.
Multithreading and multi-core Socs put an emphasis onto simultaneous multiprocessing and its support in the operating system. Dennis and Van Horn’s famous paper Programming Semantics for Multiprogrammed Computations introduced the world to the idea of capability-based kernels – an interesting way to handle permissions by a ‘token’ data structure.
Fuchsia uses this design pattern instead of the ACLS found in other operating systems, and finally switched to the microkernel pattern. This means that most drivers (such as file systems) live outside of the kernel – binary blobs provided from vendors are less critical and can be integrated more easily. In short, Fuchsia does bring theoretical concepts to life. Let’s take a look…
getting Fuchsia
Google currently does not provide ready-to-run images for the Fuchsia project. Developers must, instead, compile the code themselves – not a trivial task due to the immense complexity of the codebase. We used our trusty AMD FX-8320 octacore, which was taxed to the max. We used Ubuntu 18.04 LTS on the host – older versions might also be able to do the trick.
The first step is to download a few components and fire off the bootstrapper script provided by Google: sudo apt-get install build-essential curl git python unzip golang curl -s “https://fuchsia.googlesource.com/ fuchsia/+/master/scripts/bootstrap?format=text” | base64 --decode | bash
Done creating a Platform Source Tree at “/home/ tamhan/fuchsia”. Recommended: export Path=”/home/tamhan/ fuchsia/.jiri_root/bin:$path”
When done, the current working folder will contain a subdirectory called fuchsia. It acts as home for the downloaded files, which are around 24GB in size – don’t worry if the download process takes quite a bit of time, due to various updates being installed. Should you dislike modifying your PATH settings, feel free to enter the emitted command into every Terminal window you intend to use with the Fuchsia tools: export Path=”/home/tamhan/fuchsia/.jiri_root/ BIN:$PATH”
At this point, setting up swap is highly recommended. While most of the compile needs less than 10GB, memory demands skyrocket to over 32GB at one point: if your 16GB RAM machine does not have enough swap, all kinds of madnesses and unresponsiveness will take place. The following sequence creates a 20GB swap file and enables it – make sure to delete it when done, and to re-enable it after reboots: sudo swapoff -a sudo fallocate -l 20G swapfile tamhan@tamhan18:/$ sudo mkswap swapfile mkswap: swapfile: insecure permissions 0644, 0600 suggested.
Setting up swapspace version 1, size = 20 GIB (21474832384 bytes)
. . . sudo swapon ./swapfile
The sources downloaded must, next, be parametrised via the set command. It is responsible for setting the target architecture and packages required: fx set core.x64 --with //bundles:kitchen_sink
. . .
Generating compile_commands took 624ms Done. Made 28103 targets from 2263 files in 13059ms
At this point, we are ready to command a deployment by entering fx build – by default, the compilation toolchain will use all cores of your machine, used the -j flag to limit core use. Keep in mind that the source code will expand to more than 100GB – on our box, the size of the folder is almost 110GB: fx build -j 7 .
Now that the compilation process has run its course,
it is time to lean back and think about what we have just done. The fx command invested hours of machine time to create a bootable image of the Fuchsia operating system. It can be run on real hardware or inside the
QEMU emulator – for reasons of brevity, the QEMU environment has to suffice for now.
Due to the above-mentioned decision to base the GUI stack on Vulkan, the Qemu-based virtual machine is not able to run programs which use the GUI. This, however, is not excessively significant for us: most, if not all, GUI development for Fuchsia takes place in Flutter. It can also be run on an Android device, your desktop or – in a limited manner – in a web browser of choice.
Fuchsia can be started in graphical or textual mode. The easiest way involves the text mode, which can be activated with: fx run
Don’t worry if QEMU emits a significant amount of errors during start-up: all Fuchsia builds are debug builds, and thus by definition extremely chatty. A start-up time in the range of about one minute also is normal. Finally, do keep in mind that the prompt is not shown by default – press the Return key a few times to make it appear when the start-up messages stop scrolling by. Should you feel like using the graphical mode, enter the following command sequence instead:
fx run -g
Sadly, our VM can not provide the full experience – you are, instead, limited to a multi-tab command line. Should you find yourself on a workstation which supports kernel mode virtualisation, QEMU’S performance can be increased significantly by taking advantage of this feature. This requires adding an additional parameter to the invocation – in the case of the graphical run, the correct command would be fx run -g -k .
In a fashion not dissimilar to Android’s RDB, debugging on Fuchsia devices takes place via a network connection. When working inside of QEMU, start out by entering the following two commands to configure your workstation for a virtual networking port:
sudo ip tuntap add dev qemu mode tap user tamhan sudo ifconfig qemu up
Be aware that the top command contains the username of the account which is to interact with the network - if you, as expected, are not called tamhan , make sure to modify the command before entering it. Next, change the startup sequence of the emulator image with: fx run -k -N -u scripts/start-dhcp-server.sh
-u lets you pass in commands which are to be run on the Fuchsia virtual machine once it has started up. Google requires the oddly named command scripts/ start-dhcp-server.sh if the system is to act as a DHCP client; if you forget to pass this string to the virtual machine, the networking interface will not function.
Successfully determining the correct IP address is
then done by carefully monitoring the startup output. Fuchsia will emit information similar to the following: [00006.641] 06679:11362> [00006.640938] [723103907][0][netstack] INFO: netstack.go(379): NIC ethp0003: DHCP acquired address 192.168.3.53 for 24h0m0s
[00006.641] 06679:11362> [00006.641013] [723103907][0][netstack] INFO: netstack.go(397): NIC ethp0003: DHCP acquired subnet 192.168.3.0/24 for 24h0m0s
In our case, the correct IP address will be 192.168.3.53 – verify it by opening a second terminal on the host workstation and firing off the ping command, which will be answered. At this point in time, you can enlist the services of fx to fire off various commands. Due to the diversity of languages supported by Fuchsia, we not delve further into this – the documentation has ‘Getting started’ guides for each of the languages.
Shutting down the emulator is done via the dm shutdown command. Knowing this is handy for multiple reasons – should you ever find yourself locked into a QEMU session, kill Fuchsia to return control to your workstation:
$ dm shutdown
[00550.627] 05033:05048> minfs: Unmounted
Layer cake
Fuchsia is made up of four interconnected layers. The bottom layer, called Zircon, consists of the kernel. An interesting aspect of this is the Fuchsia interface design language, or FIDL for short. It is a programminglanguage-independent format to enable programs in various languages to interact with one another without serialisation issues; the kernel is involved in the creation of the channels.
FIDL code is relatively simple; here’s a small example taken from Google’s official Echo tutorial, which exchanges strings between two programs. Should you feel like diving into IPC yourself, feast your eyes upon https://fuchsia.dev/fuchsia-src/development/ languages/fidl: library fidl.examples.echo; [Discoverable] protocol Echo {
Echostring(string? value) -> (string? response); };
The layer above, called Garnet, will make old-timers smile instantly due to the Palm OS connotation. It provides elementary operating services such as a GUI stack or device drivers; most of them are not part of the microkernel. It also contains the updating service – it is part of the operating system and works on a very modular level, as Google is quite fed up of the neverending battle with licensees releasing operating system updates in time.
The layers above, called Peridot and Topaz, are responsible for the actual implementation of applications and runners which execute interpreted languages. Keep in mind that Fuchsia programs come as modules which are made up of multiple different components; flexibility is one of the core tenets of the operating system specification.
Diving deeper
Covering the entity of an operating system in one article is impossible, and due to the early development stage of the Fuchsia project, documentation has not been finalised. There is however a somewhat official developer website at https://fuchsia.dev.
Sadly, as of this writing, discussions still contain a variety of links pointing to the website https://fuchsia. googlesource.com/docs/+/master. Google has since taken it offline; you’ll just get a message that the material was obsoleted. In many cases, the actual files can be found either by searching for the filename or by looking for the files in the official source portal, which is now found at https://fuchsia.googlesource.com/ fuchsia. Finally, keep the resource director at https:// github.com/leisim/awesome-fuchsia in the back of your mind – it is maintained by a news site, but does contain a wide variety of interesting resources.
Due to the relatively early stage of the project,
Fuchsia updates are key “Google is quite fed up of the neverending battle with licensees releasing OS updates in time.”
developers are currently highly interested in receiving user feedback. The best way to provide your opinions involves visiting the IRC channel, which can be found at the well-known Freenode IRC network.
Fuchsia is not going to replace your designer Mac, your Linux coding rig or your PCB designer’s Windows workstation. This does not, however, mean that the operating system has no future. Fuchsia is likely to see use in embedded applications with moderate real-time demands and a rich GUI – systems such as the Chromecast or various smart displays are great candidates for ‘refreshment’ in this area.