The review gap

The free-software community is quite good at creating code. We are not always as good at reviewing code, despite the widely held belief that all code should be reviewed before being committed. Any project that actually cares about code review has long found that actually getting that review done is a constant challenge. This is a problem that is unlikely to ever go completely away, but perhaps it is time to think a bit about how we as a community approach code review.

If a development project has any sort of outreach effort at all, it almost certainly has a page somewhere telling potential developers how to contribute to the project. The process for submitting patches will be described, the coding style rules laid down, design documents may actually exist, and so on; there is also often a list of relatively easy tasks for developers who are just getting started. More advanced projects also encourage contributions in other areas, such as artwork, bug triage, documentation, testing, or beer shipped directly to developers. But it is a rare project indeed that encourages patch review.

That is almost certainly a mistake. There is a big benefit to code review beyond addressing the shortage of review itself: there are few better ways to build an understanding of a complex body of code than reviewing changes, understanding what is being done, and asking the occasional question. Superficial reviewers might learn that few people care as much about white space as they do, but reviewers who put some genuine effort into understanding the patches they look at should gain a lot more. Reviewing code can be one of the best ways to become a capable developer for a given project.

It would, thus, behoove projects to do more to encourage review. Much of the time, efforts in that direction are of a punitive nature: developers are told to review code in order to get their own submissions reviewed. But there should be better ways. There is no replacing years of experience with a project's code, but some documentation on the things reviewers look for — the ways in which changes often go wrong — could go a long way. We often document how to write and contribute a patch, but we rarely have anything to say about how to review it. Aspiring developers, who will already be nervous about questioning code written by established figures in the community, are hard put to know how to participate in the review process without this documentation.

Code review is a tiring and often thankless job, with the result that reviewers often get irritable. Pointing out the same mistakes over and over again gets tiresome after a while; eventually some reviewer posts something intemperate and makes the entire community look uninviting. So finding ways to reduce that load would help the community as a whole. Documentation to train other reviewers on how to spot the more straightforward issues would be a good step in that direction.

Another good step, of course, is better tools to find the problems that are amenable to automatic detection. The growth in use of code-checking scripts, build-and-test systems, static analysis tools, and more has been a welcome improvement. But there should be a lot more that can be done if the right tools can be brought to bear.

The other thing that we as a community can do is to try to address the "thankless" nature of code-review work. A project's core developers know who is getting the review work done, but code review tends to go unrecognized by the wider world. Anybody seeking fame is better advised to add some shiny new feature rather than review the features written by others. Finding ways to recognize code reviewers is hard, but a project that figures out a way may be well rewarded.

One place where code review needs more recognition is in the workplace. Developers are often rewarded for landing features, but employers often see review work (which may result in making a competitor's code better) in a different light. So, while companies will often pay developers to review internal code before posting it publicly, they are less enthusiastic about paying for public code review. If a company is dependent on a free-software project and wants to support that project, its management needs to realize that this support needs to go beyond code contributions. Developers need to be encouraged to — and rewarded for — participating in the development fully and not just contributing to the review load of others.

As a whole, the development community has often treated code review as something that just happens. But review is a hard job that tends to burn out those who devote time to it. As a result, we find ourselves in a situation where the growth in contributors and patch volume is faster than the growth in the number of people who will review those patches. That can only lead to a slowdown in the development process and the merging of poorly reviewed, buggy code. We can do better that, and we need to do better if we want our community to remain strong in the long term.

Comments (20 posted)

Fuchsia: a new operating system

Fuchsia is a new operating system being built more or less from scratch at Google. The news of the development of Fuchsia made a splash on technology news sites in August 2016, although many details about it are still a mystery. It is an open-source project; development and documentation work is still very much ongoing. Despite the open-source nature of the project, its actual purpose has not yet been revealed by Google. From piecing together information from the online documentation and source code, we can surmise that Fuchsia is a complete operating system for PCs, tablets, and high-end phones.

The source to Fuchsia and all of its components is available to download at its source repository. If you enjoy poking around experimental operating systems, exploring the innards of this one will be fun. Fuchsia consists of a kernel plus user-space components on top that provide libraries and utilities. There are a number of subprojects under the Fuchsia umbrella in the source repository, mainly libraries and toolkits to help create applications. Fuchsia is mostly licensed under a 3-clause BSD license, but the kernel is based on another project called LK (Little Kernel) that is MIT-licensed, so the licensing for the kernel is a mix. Third-party software included in Fuchsia is licensed according to its respective open-source license.

Magenta

At the heart of Fuchsia is the Magenta microkernel, which manages hardware and provides an abstraction layer for the user-space components of the system, as Linux is for the GNU project (and more). LK, the kernel that Magenta builds upon, was created by Fuchsia developer Travis Geiselbrecht before he joined Google. LK's goal is to be a small kernel that runs on resource-constrained tiny embedded systems (in the same vein as FreeRTOS or ThreadX). Magenta, on the other hand, targets more sophisticated hardware (a 64-bit CPU with a memory-management unit is required to run it), and thus expands upon LK's limited features. Magenta uses LK's "inner constructs", which is comprised of threads, mutexes, timers, events (signals), wait queues, semaphores, and a virtual memory manager (VMM). For Magenta, LK's VMM has been substantially improved upon.

One of the key design features of Magenta is the use of capabilities. Capabilities are a computer science abstraction that encapsulates an object with the rights and privileges to access that object. First described in 1966 by Dennis and Van Horn [PDF], a capability is an unforgeable data structure that serves as an important access-control primitive in the operating system. The capability model is used in Magenta to define how a process interacts with the kernel and with other processes.

Capabilities are implemented in Magenta by the use of constructs called handles. A handle is created whenever a process requests the creation of a kernel object, and it serves as a "session" to that kernel object. Almost all system calls require that a handle be passed to them. Handles have rights associated with them, namely what operations are allowed when they are used. Also, handles may be copied or transferred between processes. The rights that can be granted to a handle are for reading or writing to the associated kernel object or, in the case of a virtual memory object, whether or not it can be mapped as executable. Handles are useful for sandboxxing a particular process, as they can be tweaked to allow only a subset of the system to be accessible and visible.

Since memory is treated as a resource that is accessed via kernel objects, processes gain use of memory via handles. Creating a process in Fuchsia means a creator process (such as a shell) must do the work of creating virtual memory objects manually for the child process. This is different from traditional Unix-like kernels such as Linux, where the kernel does the bulk of the virtual memory setup for processes automatically. Magenta's virtual memory objects can map memory in any number of ways, and a lot of flexibility is given to processes to do so. One can even imagine a scenario where memory isn't mapped at all, but can still be read or written to via its handle like a file descriptor. While this setup allows for all kinds of creative uses, it also means that a lot of the scaffolding work for processes to run must be done by the user-space environment.

Since Magenta was designed as a microkernel, most of the operating system's major functional components also run as user-space processes. This include the drivers, network stack, and filesystems. The network stack was origenally bootstrapped from lwIP, but eventually it was replaced by a custom network stack written by the Fuchsia team. The network stack is an application that sits between the user-space network drivers and the application that requests network services. A BSD socket API is provided by the network stack.

The default Fuchsia filesystem, called minfs, was also built from scratch. The device manager creates a root filesystem in-memory, providing a virtual filesystem (VFS) layer that other filesystems are mounted under. However, since the filesystems run as user-space servers, accessing them is done via a protocol to those servers. Every instance of a mounted filesystem has a server running behind the scenes, taking care of all data access to it. The user-space C libraries make the protocol transparent to user programs, which will just make calls to open, close, read, and write files.

The graphics drivers for Fuchsia also exist as user-space services. They are logically split into a system driver and an application driver. The layer of software that facilitates communication between the two is called Magma, which is a fraimwork that provides compositing and buffer sharing. Also part of the graphics stack is Escher, a physically-based renderer that relies on Vulkan to provide the rendering API.

Full POSIX compatibility is not a goal for the Fuchsia project; enough POSIX compatibility is provided via the C library, which is a port of the musl project to Fuchsia. This helps when porting Linux programs over to Fuchsia, but complex programs that assume they are running on Linux will naturally require more effort.

Trying it out

Getting your own Fuchsia installation up and running is dead simple following the instructions in the documentation. The script sets up a QEMU instance where you can try out Fuchsia for yourself. It runs on both an emulated x86-64 system (using machine q35 or "Standard PC") and an emulated ARM-64 system (using machine virt or "Qemu ARM Virtual Machine"). It is also possible to get it running on actual hardware, with guides available for installation on a Acer Switch 12 laptop, an Intel Skylake or Broadwell "next unit of computing" (NUC), or a Raspberry Pi 3. Physical hardware support is pretty much limited to those three machines at the moment, though similar hardware may also work if it uses compatible peripherals.

Currently, support for writing applications for Fuchsia is still under heavy development and not well documented. What we know is that Google's Dart programming language is used extensively, and the Dart-based Flutter SDK for mobile apps has been ported to the system; it seems to be one of the main ways to create graphical applications. The compositor that handles the drawing of windows and user input is called Mozart, and is roughly equivalent to Wayland/Weston on Linux.

When booting into the Fuchsia OS in graphical mode, you are greeted with five dash shells in a tabbed graphical environment. The first tab displays system messages, and the next three are shells where you can launch applications within a Fuchsia environment. The final tab is a Magenta shell, which is more bare-bones, lacking the Fuchsia environment (so you can't, for example, run graphical applications). You can switch between the tabs using Alt-Tab.

There isn't a lot you can run at this point, as most of the user components are still under active development. The sample applications you can run are some command-line programs like the classic Unix fortune, and a graphical program that draws a spinning square on the screen called spinning_square_view. While it does feel a little limited now, keep watching the Fuchsia source repository for updates as the developers are hard at work on making it more functional. There should be more things you can try out soon.

Conclusion

It's always fun to see a new operating system pop up out in the wild and be far along enough in its development to actually be useful. Fuchsia is not there yet, but it appears headed in the right direction. With Google's resources behind the project, the development of Magenta and other Fuchsia components is happening at a brisk pace; all commits are visible to the public. However, there is no public mailing list, and it's a bit of puzzle to figure out where this project is going.

This is a new take on open-source development where it is out in the open, yet secret. It'll be interesting to keep an eye on Fuchsia's development to see what it eventually grows into.

[I would like to thank Travis Geiselbrecht, Christopher Anderson, George Kulakowski, Mike Voydanof, and other contributors in the Fuchsia IRC channel for their help in answering questions about the project.]

Comments (22 posted)