I really didn't want this to be another week where I posted about how I
was still trying to patch Wayland to do virtio_wl, and I am delighted to
have just discovered it's not going to be!
crosvm
------
I realised that emulating accept(2) for the Wayland compositor socket in
the way I'd planned would require some crosvm rework. I want to have a
host proxy program that accepts the connection, then connects the
connection socket to crosvm. I had made it possible to dynamically add
sockets to the crosvm Wl device through the control socket, but this
turned out not be enough, because crosvm would store virtio_wl sockets
in a BTreeMap<String, PathBuf>, and then use connect(2) to connect to
the socket when asked to by the guest kernel. This works fine for
e.g. connecting to a host Wayland compositor, which is what crosvm was
designed for, but it wouldn't work for opening a connection socket from
accept(2), because you can only connect to a listening socket.
So instead, I modified the `crosvm wl add' command to take a file
descriptor pointing to the connection socket. I made crosvm store
sockets as an enum that looks like this:
enum WaylandSocket {
Listening(PathBuf),
NonListening(UnixStream),
}
This way, when it gets asked by the VM to connect to a socket, it can
either connect to a listening socket at its path using connect(2), or
just use the existing file descriptor if it's a non-listening socket. A
NonListening socket will be consumed by a connection, so when the VM
close(2)s it, it'll go away, and on the host side the connection will
finish as expected. Listening sockets can be connected to repeatedly,
as before.
I also added support to `crosvm add wl' for dynamic socket names. So
it's possible to do `crosvm add wl wl-conn-%d', and connections will be
added with names like `wl-conn-0', `wl-conn-1', etc. So it's easy to
get unique names for connection sockets. The chosen name is printed by
the command, so the caller knows what name to tell the VM to connect to.
I also found and fixed a bug with the previous crosvm deadlock fix[1].
I had assumed that device_sock.recv(&mut []) would drop a message from
the (SOCK_SEQPACKET) socket, without having to read any of it. But
UnixSeqpacket::recv calls libc::read, and read(2) tells us that:
> In the absence of any errors, or if read() does not check for errors,
> a read() with a count of 0 returns zero and has no other effects.
So this was in fact doing nothing at all. I don't know why crosvm's
UnixSeqpacket::recv calls read() instead of recv(), but it's always been
like that and I'm guessing this sort of thing (from recv(2)) might have
something to do with it:
> The only difference between recv() and read(2) is the presence of
> flags. With a zero flags argument, recv() is generally equivalent to
> read(2) (but see NOTES).
So probably read() just looked like a nicer way to recv() when no flags
were needed.
But, unfortunately, zero-byte reads are when the aforementioned NOTES
section becomes relevant:
> If a zero-length datagram is pending, read(2) and recv() with a flags
> argument of zero provide different behavior. In this circumstance,
> read(2) has no effect (the datagram remains pending), while recv()
> consumes the pending datagram.
So, my assumption that UnixSeqpacket::recv(&mut []) would consume a
message turned out to be quite reasonable -- the surprising thing was
that a method called `recv' would call read() rather than recv(). I
think the best fix here will be to just make it call recv() instead,
rather than modifying my code to do UnixSeqpacket::recv(&mut [0]) or
something, to prevent further nasty surprises with this in future.
[1]: https://spectrum-os.org/lists/archives/spectrum-devel/20200614114344.22642-…
Wayland
-------
I created API-compatible implementations of the libc sendmsg(2) and
recvmsg(2) functions for virtio_wl sockets. This was quite an
achievement, because the API (which allows you to send and receive data
and file descriptors, as well as other things I don't intend to support)
is rather arcane (see the example in cmsg(3) if you're not familiar with
them). I wrote unit tests for them, and it took a long time before they
worked reliably. Once I had these, though, I could find the places
where Wayland called sendmsg() and recvmsg() and fall back to the
virtio_wl-based implementations if the standard functions failed with
ENOTSOCK. I stubbed out some stuff that isn't going to work over
virtio_wl, like looking up the pid of the Wayland client through
getsockopt(2).
I also had to resort to a few hacks, like faking support for
MSG_DONTWAIT by using fcntl(2) to set O_NONBLOCK on the socket,
recv()ing from it, and then removing O_NONBLOCK again, or faking
mremap(2) by munmap()-ing and mmap()-ing. We will want to clean these
up later by implementing the required missing functionality in the
virtio_wl kernel module. In the first case, at least, this should be
pretty straightforward, because it supports non-blocking operations if
the socket is O_NONBLOCK -- it just needs to accept a MSG_DONTWAIT
option as well. The VIRTWL_IOCTL_{SEND,RECV} syscalls don't currently
have a flags argument, so that'll need to be added.
I implemented this bit by bit, at every step trying to run Alacritty on
my host system, connected to the virtio_wl Wayland server socket through
the accept() proxy, and using strace and some printf()-debugging to see
where the Wayland compositor in the VM would get stuck, and about an
hour ago, it finally worked! For the first time, a Wayland compositor
running in a VM can display an application running outside of it.
(Obviously we'll want the application to be running in another VM rather
than on the host, but that's similar enough that it probably works
already -- I just haven't tested it yet.) This feels like a huge
achievement. I've been working towards it for so long.
Next week, I'll be cleaning up this code and posting patches for all of
it. Then I'll probably move on to other sorts of device virtualization,
like running a virtual network device in a VM. I'm feeling so much more
positive about the direction of the project than I was before. It's
been difficult to make myself keep going making little progress for the
last couple of weeks, and it's great that I've managed to pick things up
again so much. I hope that the level of detail in this email is enough
to make up for the brevity of last week's! I'm sending late again, too,
but only by a couple of minutes -- I didn't expect this email to take
over an hour to write, but there we go.
Thanks for reading! I hope you're looking forward to seeing where
things go from here as much as I am.
This is going to be a very short one, and it's coming a day late,
because I have been busy and didn't want to stop yesterday. 2020-W22's
TWiS was sent a day early, so the delay is balanced out. :)
Wayland
-------
I'm finally making progress with the Wayland stuff I've been staring at
for the past two weeks! Now that I'm unblocked, things feel like
they're moving very quickly.
I've modified a Wayland compositor and libwayland-server to use a
virtio_wl socket. I've also implemented the compositor side of the
accept(2) fallback. Just now, I finished writing a proxy program that
implements the host side of that. Next up is testing it.
After that, I think we might be there? But it's also possible I have my
head so deep in it there's another bit that I've forgotten.
Another week that ended up being a detour from the Wayland work I wanted
to do, unfortunately. I think this will be the end of it, though.
crosvm
------
Fixed[1] an error in my crosvm deadlock fix[2] from last week. Due to
an oversight (obvious as soon as I tried to test the affected devices,
and from looking at the code in retrospect), this actually broke the
devices that were *not* affected by the deadlock, which I had neglected
to properly test. Fortunately, it was a very small and easy fix.
I also had an interesting (and ongoing) conversation[3] with Cole about
the deadlock fix in the mailing list thread. It's one of those
situations where getting to talk about the code with another person and
having to explain things is going to result in much better code. So
we'll end up with a much tidier fix than what I came up with on my own.
Thanks to Cole for his feedback and this opportunity. It's great to
know that somebody else is passing an eye over my code.
[1]: https://spectrum-os.org/git/crosvm/commit/?id=ca5bdd2ac3e473e9b082c44c2870f…
[2]: https://spectrum-os.org/lists/archives/spectrum-devel/20200614114344.22642-…
[3]: https://spectrum-os.org/lists/archives/spectrum-devel/CH2PR14MB357902F38908…
Wayland
-------
My current area of attention is modifying Wayland to use a virtio_wl
socket as the display socket. Preparing to start implementing that this
week, it occurred to me that working on it using my current setup was
going to be extremely time consuming. Up until now, I've been doing Nix
VM rebuilds when I want to test a change to, for example, wlroots. This
means rebuilding, in that case, wlroots and all dependencies
(i.e. Wayfire). In the case of wlroots, it's not so bad because
rebuilding two packages doesn't take all that long, but it wasn't going
to work for Wayland.
So I decided that the best way forward would be to create a VM running a
traditional Linux distribution, in which I could hack on Wayland without
having to restart the VM or rebuild all of its dependents. To that end,
I spent much of this week setting up an Alpine VM that can be run under
both crosvm and QEMU. (Configuring networking with crosvm is hard for a
one-off like this, but QEMU has a built-in userspace networking stack[4]
that makes it easy, so when I want to, e.g. install a package, I can
boot with QEMU to do that, and then go back to crosvm for testing
virtio_wl things.) This resulted in a Nixpkgs pull request[5] to
package Alpine's apk package manager, which was used in building the VM
image.
As of this afternoon, I have this VM all set up and ready to go. I have
a script that runs it under crosvm with a virtio_wl socket available to
try to connect Wayland to, and another virtio_wl socket connected to the
host Wayland compositor for testing. It also sets up some limited
networking that allows me to SSH into the VM, but does not allow the VM
to access the internet. A separate script runs the VM under QEMU with
full networking. The VM has Wayland, wlroots, and Sway (the choice of
wlroots-based compositor is irrelevant to this work, and Sway is easier
to build) installed from source, and because I can SSH to it I can edit
files in the VM easily from my host Emacs using TRAMP[6].
All of this will allow me to iterate on the Wayland work without having
to wait upwards of an hour to test each change. This was actually the
first time I'd ever booted a VM image in crosvm that I hadn't generated
specifically for that purpose myself with Nix. I improved my
understanding of crosvm in a few ways in the process (although not
anything concrete enough I can think of to write down here).
[4]: https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
[5]: https://github.com/NixOS/nixpkgs/pull/90676
[6]: https://www.gnu.org/software/tramp/
Next week, I'll continue with the Wayland work. It shouldn't be all
that much work in the end, but getting set up to actually be able to do
it has been annoyingly complicated.
An interesting week. Didn't go quite in the direction I expected it to.
Documentation
-------------
Cole kindly provided[1] some documentation[2] for spectrum-vm for the
developer manual. This was especially nice, because it marked the first
time I was able to remove[3] an item from the Contribution Ideas page[4]
because somebody had done the contribution! Thanks Cole!
[1]: https://spectrum-os.org/lists/archives/spectrum-devel/87zh97coks.fsf@alyssa…
[2]: https://spectrum-os.org/doc/developer-manual.html#_spectrum_vm
[3]: https://spectrum-os.org/git/www/commit/?id=bf7cde0ddd06455f212fb39092b87313…
[4]: https://spectrum-os.org/todo.html
crosvm
------
My main goal for this week was to start modifying libwayland-server to
use a virtio_wl socket as the display socket, as described last week[5].
So, in pursuit of this goal, I started the week by trying to write a
test program that would start a VM running a compositor, create a
socket, attach one end to that VM, and then start another VM running a
Wayland client, and attach the other end of the socket to that VM.
Then, in theory, all I had to do was the libwayland-server
modifications, and then the compositor and client would be able to talk
to each other.
Unfortunately, I didn't get that far. The program froze after starting
the first VM. I assumed I must have done something wrong, so I rewrote
it, and had the same problem. I did it again, and same problem.
Some further debugging revealed that the command to add the socket to
the first VM was hanging. And also, crosvm was hanging. Running the
command outside this program worked fine, though. It returned
immediately, and crosvm kept running with the new socket added.
What I eventually realised was that the crosvm hang only happened if the
command was sent to it early enough. After some intense staring at the
crosvm code, I realised that there was a deadlock resulting from trying
to wait for a response from a virtual device before the device had been
initialized. Despite this issue manifesting with adding Wayland
sockets, which is a feature unique to crosvm, a lot of the code for that
is adapted from the code for resizing virtual block devices, which is an
upstream feature. And that had the same issue, so this is actually an
upstream bug.
The fix was not easy, and required some fairly substantial refactoring.
It's described in detail in the patch message[6]. I think it's probably
a pretty interesting read.
I also merged in the latest upstream crosvm changes.
[5]: https://spectrum-os.org/lists/archives/spectrum-discuss/87tuzm287b.fsf@alys…
[6]: https://spectrum-os.org/lists/archives/spectrum-devel/20200614114344.22642-…
Nixpkgs
-------
I spent a few more hours trying to get libvda (an optional dependency of
crosvm; required for virtio-video) to build, and I got it to work,
thanks to some help from Puck. There's still a hack in there I'll tidy
up before I push it, but it's cool to have this packaged for future
experimentation with this crosvm feature.
With the crosvm issue out of the way, which ended up taking most of the
week to identify and fix, hopefully next week I'll be able to actually
get going on those libwayland-server changes.
I wasn't quite back up to normal speed after being sick last week, I
think, but we're getting somewhere and I did some cool stuff!
Infrastructure
--------------
Upgraded Mailman. Most significantly, the Hyperkitty UI has some nice
improvements, which I think will make it easier to navigate. :)
Nixpkgs
-------
I integrated and committed last week's wlroots patch (to make it
use virtio_wl-compatible memfds).
Spent quite a lot the start of the week working on packaging more
Chromium OS components to build some optional crosvm features. They
just added support for virtio-video[1], which sounds pretty cool. I
managed to get libchrome working again, which I previously had to remove
because I couldn't get it to build! I haven't committed any of this
yet, because I haven't got to the point where it's useful for building
optional crosvm features, and I don't want to add packages that aren't
useful for anything, but I did make quite a lot of progress. After a
couple of days of this, though, I put it aside to focus on other things,
since it would be useful to have, but its not a priority right now.
[1]: https://chromium.googlesource.com/chromiumos/platform/crosvm/+/57df6a0ab23c…
crosvm
------
I posted a patch[2] to make listing a directory shared with --shared-dir
not crash crosvm when sandboxing was enabled. I'd been reluctant to fix
this, because --shared-dir (which exposes a host file system to a crosvm
guest) is not going to be useful in Spectrum, where shared directories
should come from another VM. But it's useful enough in development that
not fixing it was more frustrating than just fixing it.
I spent a lot of time this week thinking about Wayland connections. My
original plan for inter-VM communication was to make it possible to run
crosvm devices as standalone programs inside VMs. I still think this is
the right track for most virtio devices, but for Wayland it's starting
to feel less and less like it makes sense, because the Wayland device is
basically a wrapper around a socket, and both ends will be hooked up to
sockets. So what I now plan is that a VM running a Wayland client
application will connect to a host socket, with the other end connected
to a VM running the compositor. The client applications will be run
under Sommelier, and so will be able to run unmodified. The compositor
will be modified to use a virtio_wl socket.
A slight complication here is that a Wayland compositor usually accepts
on a socket to receive client connections, but you can't accept on a
virtio_wl context. So instead, what we can do is emulate accept by
attaching a new virtio_wl socket, and then sending the name of that
socket over the main socket. This can be wrapped inside the VM to look
very much like an accept. Unfortunately, crosvm virtio_wl sockets could
only be set at startup time. So today I fixed that[3]. Adding support
for adding virtio_wl sockets at runtime was pleasantly straightforward.
I feel very energized now that I managed to bang that out in a day. :D
[2]: https://spectrum-os.org/lists/archives/spectrum-devel/20200605234757.28848-…
[3]: https://spectrum-os.org/git/crosvm/commit/?h=interguest
This is one of those weeks where I can feel writing this that it might
not make much sense to anybody else. But the important thing with these
weekly updates is that I write _something_ we can refer back to in
future, and communicate that things are happening. If you'd like to
better understand what I'm talking about here, I'm happy to try walking
through it on IRC.
Next week, I'm going to work on getting libwayland-server to speak this
weird virtio_wl faux-accept.
I began this week feeling very burnt out from some Nix stuff. Later in
the week, I got sick as well (thankfully not with any COVID-19 symptoms)
and ended up spending several days not being able to do much beyond
sleep. So, not a lot from me to report this week I'm afraid. This'll
be a short one.
Documentation
-------------
I documented the memfd server I recently added to crosvm[1]. I sent the
documentation patch to the list, and was very pleased to receive
reviews[2] from impaqt and Cole Helbling. This is really the first time
a patch from me has gone through an actual review cycle with other
people involved, so that's very exciting. Here's to more of that! :)
With that documentation, I was then able to add a memfd server quota to
the Contribution Ideas page[3]. This is an important feature, so if
nobody is interested in working on it I'll do it myself, but it's also a
nice opportunity to do a pretty self-contained bit of work on crosvm, so
I'm going to leave it up for a bit in case somebody else wants to try
it.
[1]: https://spectrum-os.org/doc/developer-manual.html#_the_memfd_server
[2]: https://spectrum-os.org/lists/archives/spectrum-devel/C312TALEYVQS.RICE3VLE…
[3]: https://spectrum-os.org/todo.html
Infrastructure
--------------
Increased the maximum message size on devel@ to 80K from 40K, because a
patch I sent was too big and got held for moderation.
Nixpkgs
-------
The expected Chromium OS update was released this week (instead of last
as I'd expected). crosvm now wants the minijail source code, which
isn't hosted on chromium.googlesource.com. This required making the
update script a bit smarter. I posted the patch series improving the
update script and then updating chromiumOSPackages to the list[1]. More
details there.
Another shout out to Cole for having a go at doing this update, even if
he didn't get all the way because he needed the cores on his computer
for other things. Thanks Cole!
[1]: https://spectrum-os.org/lists/archives/spectrum-devel/20200530190028.6388-1…
I'm mostly feeling better now (although still getting tired very
easily), so hopefully things will go faster again next week. Too early
to be certain, though. I'm happy to have at least got the
chromiumOSPackages update out the way, and delighted to have received
the reviews on the documentation patch.
A week of results!
Infrastructure
--------------
Fixed a misconfigured spam filter that allowed an obvious spam message
through to devel@. Oops.
crosvm
------
Integrated the memfd server[1] on the interguest branch. It's now all
sandboxed, and optionally enabled with a command line argument to crosvm
run. Not all that much to say here, but it's what took me most of the
week!
Getting the sandbox working was a bit weird. When I tried to get it to
log seccomp failures, it seemed to just disable the sandbox. I had to
track them down with strace instead. Annoying. But the sandbox does
work in normal operation.
I still haven't limited how much memory can be requested this way. I
think implementing that would be relatively straightforward for another
contributor, so I think I'll add it to the ideas list[2] and see if a
patch is forthcoming. Otherwise I'll do it myself.
[1]: https://spectrum-os.org/git/crosvm/commit/?h=interguest
[2]: https://spectrum-os.org/todo.html
wlroots
-------
I took my standalone virtio_wl test program, and integrated it into
wlroots' allocate_shm_file function. This has the result that, when
running under Sommelier, this patched wlroots will request shared memory
from the host, rather than allocating it itself. Porting from the
standalone test program was nice, because it meant that this all just
worked, first try! (Once I got it to compile under Nixpkgs' or wlroots'
strict compiler errors, at least.) This will allow that memory to be
sent between VMs!
I haven't pushed the patch yet because I haven't integrated it into
Spectrum's Nixpkgs yet. I plan to do that next week. I'm starting to
think about moving the stuff specific to Spectrum VMs into an overlay,
but I need to think a bit about how to structure that.
Nixpkgs
-------
There's no sign of the expected Chromium OS release so far, so I
backported[3] support for multiple virtio_wl sockets from a more recent
Chromium OS kernel to the one in Spectrum's Nixpkgs. We need this to be
able to dedicate a named socket to the memfd server.
[3]: https://spectrum-os.org/git/nixpkgs/commit/?id=f24d310275909265de32cbc831d5…
It's been another week where I've been very focused on one task. I'm
quite excited about the direction this is all going. It's looking like
we'll be able to do almost everything inside VMs, which means it might
be possible to have a host kernel that does almost nothing apart from
KVM and PCI passthrough?? This would mean we'd end up with a tiny Linux
a little bit (but not all that much) like a microkernel, with most
hardware interaction and all user programs running in VMs. Cool stuff!
It's not clear to me yet the exact extent to which this is achievable,
but it's a nice vision to keep in mind. It might also make it easier
for us to transition to a true microkernel at some point in the future.
I'm hoping that I'll hit an NLnet milestone related to this stuff fairly
soon. Until I do, I'm now living on the money I've received in the past
six months through GitHub Sponsors. Thank you so much to everyone who
is helping to make it possible for me to spend this time on the
fundamentals so we have a good foundation to build Spectrum on. <3
It feels like things are finally starting to come together.
Infrastructure
--------------
Server memory upgraded. We should now be able to handle more than one
person cloning Spectrum's nixpkgs repo at once!
Documentation
-------------
I added a much requested page[1] to the website with a few tasks a
potential contributor might want to look into. More to come here, too!
[1]: https://spectrum-os.org/todo.html
virtio_wl
---------
I wrote a simple guest C program that connected to a host socket over
virtio_wl, and sent some messages back and forth. In doing this, I've
ended up with a nice set of generic functions for interacting with
virtio_wl -- virtio_wl_connect(), virtio_wl_send(), etc. This is nice,
because it allows me to treat virtio_wl inside a guest much like a
regular socket (albeit one that can only be interacted with using a
custom set of functions). Otherwise, I'd have to do ioctl operations
every time (which seems to be what the various virtio_wl-using Chromium
OS components do).
Having a simple test program (rather than integrating directly into
wlroots) gives me a more simple environment with which to test the other
end of this connection.
crosvm
------
I implemented a little Rust server that listens on a Unix stream socket.
When it receives a message (consisting of an identifier {for debug
purposes} and a size), it will allocate a memfd of the requested size,
and then send that back to the socket, along with a status byte
indicating success or failure.
I then integrated this program into crosvm, so it is started as part of
the VM initialization, and exposed over virtio_wl as an additional
socket. Integrating this into crosvm required some careful thought,
because there's no precedent in crosvm for a virtio_wl server of this
sort. It has almost nothing with the existing concept in crosvm of a
"device", which is something that communicates with a guest kernel
driver over PCI. So Spectrum's crosvm now has the concept of
"servers". I can see us wanting to provide other VM services over
virtio_wl in the future. It allows us to exchange various resources
between host and guest (or between guests) without having to write a
kernel driver specific to each task.
This all now works well enough that my program inside the VM can request
a chunk of memory, and receive back something that looks a bit like a
memfd, that can then be sent back to the host over a virtio_wl socket.
It was great to see this working the first time!
One thing crosvm devices do that I would also like to apply to this type
of server is sandboxing. The sandboxing mechanism used in crosvm is
pretty generic (it's really just a thin wrapper around Minijail[2]), so
it should be straightforward to reuse. I just have to understand a bit
better how to use it.
The other crosvm change I still need to make is to put this
functionality behind a command line flag. Most VMs should not be able
to give themselves extra memory this way -- really only the Wayland
compositor should be using it. I should also impose some upper bound on
how much memory is allowed to be allocated this way. Such a limit will
probably get harder to add (from a testing point of view) the longer I
wait.
[2]: https://lwn.net/Articles/700557/
So, at lot of very focused progress this week. From here I plan to
finish up the crosvm stuff, and then integrate this protocol into
wlroots. Then, not too long from now, we'll finally be able to move the
Wayland compositor into its own VM, separate from applications.
Exciting!
There will also probably be a Chromium OS release next week, which will
require some updates in Spectrum. If all goes well, I won't actually be
the one doing that this time. ;)
> I think that's it for this week, although honestly there have been so
> many different things going on I've probably missed something.
Oh, I know what I forgot!
cgit
----
I upgraded <https://spectrum-os.org/git/> from cgit 1.2.1 to 1.2.3,
which involved bumping cgit in Nixpkgs[1].
[1]: https://github.com/NixOS/nixpkgs/pull/87412
Nix
---
This actually happened last week, but I forgot it then too. It also is
_technically_ not Spectrum work, but it's an issue with an important
Spectrum component that I found while working on Spectrum.
I found and fixed a denial-of-service issue in Nix that would let a
malicious derivation permanently break Nix store garbage collection
until the administrator manually intervened.
The commit message[2] has an extremely detailed write-up of what went
wrong. Thanks to puck for helping me with the reproduction and fix.
[2]: https://github.com/NixOS/nix/commit/c05e20daa1abb3446e378331697938b78af2b3d7
This week, I want to give a special shoutout to Cole Helbling, who sent
three patches to improve our documentation. Non-Alyssa Spectrum patches
are quite rare at the moment, so it was very very nice to get these all
at once. Thanks Cole!
This week has mostly been tidying up loose ends and working on
documentation. But there's some good, concrete progress as well.
Website
-------
<https://spectrum-os.org/> now links directly to my blog and This Week
in Spectrum, so that people who come to the website can more easily see
that development is ongoing and progress is being made[1]. I've also
made it a little more obvious how to find the IRC channel and mailing
lists from the homepage[2], because a conversation on the fediverse made
me realise that wasn't clear at all before.
Cole fixed the advice in the website's CONTRIBUTING file on sending
patches for the website[3]. I had written to set Git's
"sendemail.subjectPrefix" configuration option, but the option is
actually called "format.subjectPrefix".
Cole fixed a broken link[4], and I made the incorrect URL redirect to
the right one as well, just in case.
[1]: https://spectrum-os.org/git/www/commit/?id=8f37213cfd4d5dbd4a982bfc1899a3b3…
[2]: https://spectrum-os.org/git/www/commit/?id=6d1ce779016cd84c0413b225355715e5…
[3]: https://spectrum-os.org/git/www/commit/?id=8f37213cfd4d5dbd4a982bfc1899a3b3…
[4]: https://spectrum-os.org/git/www/commit/?id=13c860e1e5bb02fce683012b851c4451…
Developer manual
----------------
Did you know there's a developer manual[5] for Spectrum? There's not a
lot in there yet, so for now it might not be all that useful, but it
will be one day! I added a section about how to hack on Spectrum's
crosvm, because it can be a bit non-obvious how to get up and running
with it. I got some great feedback on it on IRC, and a diff from Cole
with some fixes. Thanks to everybody who gave me feedback and helped
get that documentation into shape. Setting up a crosvm build still
isn't all that easy, but at least it's documented.
[5]: https://spectrum-os.org/doc/developer-manual.html
Infrastructure
--------------
Two(?) people trying to clone all of Nixpkgs from the tiny VPS running
spectrum-os.org caused the server to run out of memory and return 504 to
those clones. It's quite important that people are able to get
Spectrum's code, so I've arranged for the VPS to be upgraded with more
memory, and so now I just need to reboot the machine so it picks it up.
I plan on doing this tomorrow, since there's less likely to be mailing
list traffic then than there is immediately after I send this.
In the medium term I'll host all this stuff on a more sensible machine,
because it's quite clear the workload on this server (which also runs
some other stuff) is starting to get beyond the "tiny VPS" territory.
IRC
---
Activity in #spectrum has really picked up all of a sudden. Hundreds of
messages were sent in the second half of this week, mostly talking
either about Spectrum or about the future of secure computing in
general, and I'm extremely here for all of it. The best thing is that I
wasn't even around for most of these conversations!
It's hugely motivating to me to feel that people are so interested in
Spectrum, and it's great to have people with all sorts of useful
knowledge and questions around.
If you weren't there, I recommend actually checking out the logs from
this period[6], because the conversations being had were just a great
read full of interesting stuff.
#spectrum feels like it's now at the point where you can start a
discussion about secure computing, and be confident that you'll get
at least a couple of extremely knowledgeable people involved in the
conversation, and that's just fantastic.
[6]: https://logs.spectrum-os.org/spectrum/2020-05-06
Wayfire
-------
I replaced Sway in the test VM derivation with our newly packaged
Wayfire. I was worried at first because wf-shell wasn't starting
properly, but strace helped me realise that wf-shell likes HOME to be
set, and I hadn't actually done that in the VMs yet. So now that works.
There hasn't been much movement on my Wayfire PRs, or my PR to add
Wayfire to upstream Nixpkgs, and that's down to me. I felt like after
working on it all week last week, I needed a bit of a break. I'll try
to get back to it next week so all those PRs can be gotten over the
line.
crosvm
------
I merged the latest crosvm changes from Google into Spectrum's crosvm
tree. Doing this at the moment takes quite a while, because my
work-in-progress "interguest" branch has about 50 commits that have to
be rebased onto the new master, and quite a lot of those usually result
in conflicts. This won't be as much of a problem once that code is
ready to be included in master, because updating then will just be a
single merge commit, but for now it's a bit of a pain, especially since
I try to make sure every commit works.
I haven't had much of a look over what's changed yet. There's usually
at least one cool new toy to be excited about when I merge Google's
crosvm, though, so I look forward to finding out what it is this time.
I think that's it for this week, although honestly there have been so
many different things going on I've probably missed something.
Hopefully next week will be a bit more focused and I'll make more
progress with interguest communication. This week, though, we've made
some great improvements in several important areas. I'm optimistic that
the increased IRC and patch volume are a sign of things to come. I'm
looking forward to seeing where things will go from here. :)
