January 4, 2018

Harfbuzz Adventures

Lately, I've been thinking about text layout in Rust. We'll get back to that at some point. This led to me to looking at the Rust bindings for Harfbuzz. Since then, I've started some submitting some fixes to the Rust bindings, including working towards updating to the current version of Harfbuzz. (This was a couple of weeks ago. Then I went on an extended holiday.)

Then, I decided to look at making some improvements upstream in Harfbuzz. I've now had a few minor patch submissions (#669, #670) accepted there as well and am working on more, including improving the support for the cmake build system.

One annoying thing is that since I use ninja as a build tool (instead of make), I have to modify many projects to include this bit of configuration (#674):

if (UNIX AND CMAKE_GENERATOR STREQUAL "Ninja")
  if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
    set (CMAKE_CXX_FLAGS "-fcolor-diagnostics ${CMAKE_CXX_FLAGS}")
    set (CMAKE_C_FLAGS "-fcolor-diagnostics ${CMAKE_C_FLAGS}")
  endif ()
  if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
    set (CMAKE_CXX_FLAGS "-fdiagnostics-color ${CMAKE_CXX_FLAGS}")
    set (CMAKE_C_FLAGS "-fdiagnostics-color ${CMAKE_C_FLAGS}")
  endif ()
endif ()

This gets old! I wish this could be fixed upstream somewhere, but I haven't had the time / motivation myself to think about this.

I also noticed when building on macOS that there were a large number of warnings due to usage of some APIs that had been deprecated with macOS 10.12. Since this was over a year old, I figured that I would take a look. While I consider working on making it use C++11 std::atomic, I submitted an easy fix (#676) for now that makes it use the compiler primitives that are already used on Linux.

It looks like there's a good bit of stuff in Harfbuzz that could be cleaned up some. I started looking at it to improve the docs so that the Rust bindings would have better docs, but now I'm working on the build system and looking at some minor issues in the code.

GTK-Doc

I started working on getting the docs for Harfbuzz to build with cmake as well. This led me to finding that Harfbuzz uses GTK-Doc for its documentation. Unfortunately, the integration files that are shipped with GTK-Doc are broken. I've submitted a fix upstream. I noticed that others have run into this as well, but no fix was done.

There are still things to do here. I suspect that the docs for using cmake with GTK-Doc are not entirely correct. And now that someone is using it, there may need to be a way to pass different flags or otherwise improve the process.

Z3

This week, I also submitted some fixes for minor issues in the Z3 theorem prover that I'd been working on over the holidays. These weren't terribly exciting, but are a start on helping to improve code quality. I hope to continue doing this at random points in time in the future.

Spectre and Meltdown

The big news today has been the release of the information about the attacks on CPUs.

I wonder how RISC-V will respond and how vulnerable (or not) it is to these sorts of things. Does it benefit by being less advanced? Is this a point at which having the full source for your CPU could be an asset, and you aren't necessarily at the mercy of a single vendor, like Intel? (Not that this would be an easy problem to fix for anyone...)

Also, how will this impact all of the hobbyist and other small scale OSes out there? SeL4 has indicated that they're working om this. How about Fuchsia and others?

What impact might this have on the design of a kernel? If syscalls (or really any transition between security contexts) must become more expensive, is there room to think about changing how we think about syscalls? In the past, I've thought about how many programs are effectively querying the kernel for data piece by piece rather than being able to write a single query that would return the data that they want, much like GraphQL or SPARQL. I'm not suggesting using an actual query language with a textual representation, but treating things within the OS as items in a graph and being able to operate at that level might be interesting.

Similarly, it seems like some of the mitigations being discussed and pushed out could be done in a better way in a language like Rust than in C / C++. An example of this might be ARM's __builtin_load_no_speculate as a new compiler primitive.