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):

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.