general high-level discussion about spectrum
 help / color / mirror / Atom feed
From: Alyssa Ross <>
Subject: This Week in Spectrum, 2020-W23
Date: Sun, 07 Jun 2020 15:42:48 +0000	[thread overview]
Message-ID: <> (raw)

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]

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!


Upgraded Mailman.  Most significantly, the Hyperkitty UI has some nice
improvements, which I think will make it easier to navigate. :)


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.



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


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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

                 reply	other threads:[~2020-06-07 15:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).