From: Alyssa Ross <hi@alyssa.is>
To: devel@spectrum-os.org
Cc: discuss@spectrum-os.org
Subject: This week in Spectrum
Date: Sun, 12 Apr 2020 16:30:13 +0000 [thread overview]
Message-ID: <87d08cll9m.fsf@alyssa.is> (raw)
[-- Attachment #1: Type: text/plain, Size: 5102 bytes --]
Before we begin, **if you are subscribed only to the discuss mailing
list**, I'd like to hear from you whether you'd like future weekly
development updates to come to you or not, because I'm not really sure
whether this sort of update belongs on the devel mailing list, or the
discuss one. So for this initial edition, I'm sending to both, but I
probably won't do that going forward.
So, as I wrote in the recent status update on my blog, I'm going to try
weekly(?) mailing updates instead of lengthy blog posts every few
months. I was going to start last week, but I ended up taking most of
the week off because I'd been working every day for a long time and was
starting to find it difficult to concentrate. But I'm back now, and
this week has been a good one.
Spectrum Live
-------------
(This was actually last week, but I felt this deserved a mention.)
A bit more than a week ago now, I did a live stream where I showed
myself working on a fairly simple change to crosvm. Viewer numbers
stabilised at around 11, and we had a lively IRC conversation, which I
was pleasantly surprised by. I ended up spending most of the stream not
working on that change, but instead explaining how various things in the
system will work, and helping getting a couple of people started running
the Spectrum code. By the end of the stream two people had succeeded in
this, and that means two people who are set up to work on Spectrum. One
was even starting work on trying to build a smaller kernel for Spectrum
VMs!
Overall I think this was extremely successful, and I'll try to do it
again soon. I'll announce the stream a bit ahead of time in #spectrum
on Freenode.
crosvm
------
Having previously split crosvm into two separate programs -- one to run
a virtual device, and one to run a device VM -- I further split it into
three programs. This might sound a bit silly, but here's the idea --
one program is the crosvm that runs an application VM, the second will
become part of the crosvm that runs a device VM, and the third will be
the device implementation itself, that will run inside the device VM.
As a reminder, the overall idea here is to put virtual devices into
their own VMs, rather than being run directly on the host.
I also pulled in the latest changes from Google. Of particular note is
commit 146450b, which updates the msg_socket library to support
dynamically sized messages. If you're paying attention, you'll recall
that I just wrote my own serde-based replacement for msg_socket because
I needed to do exactly this. That work might now have been superseded,
but I'm not sure yet. msg_socket2 uses SOCK_STREAM sockets (which can
be used between VMs or VM<->guest), while msg_socket uses
SOCK_SEQPACKET, which can't. I haven't checked whether msg_socket's new
implementation could work without SOCK_SEQPACKET-style preserved message
boundaries -- if it can't, msg_socket2 will stick around. msg_socket2
also properly handles file descriptor lifetimes using the borrow
checker. This means that safe Rust code can't send closed or
non-existent file descriptors over msg_socket2. msg_socket does not do
this, because it just represents file descriptors as integers with no
lifetime information. Whatever happens to msg_socket2, at some point
I'll want to make msg_socket do file descriptor lifetimes properly. In
general, it's not clear from existing documentation how to properly
handle file descriptor lifetimes in Rust, and so I plan a blog post on
this topic soon.
The next problem is to figure out communication between the device VM
and the device crosvm. The protocols currently in use rely on being
able to share memory using file descriptors, which is not possible
between a VM and the host. To avoid using file descriptors, I would
have to change those protocols, possibly on a per-device basis, which
would be a lot of work, and might have to be done again whenever crosvm
adds a new device type. But, I think I might have a better, if
surprising solution. Despite its name, the Virtio Wayland protocol has
almost nothing to do with Wayland. Instead, it's a fairly generic
socket-like protocol that allows sending "virtual file descriptors" of
certain specific types between a VM and its host. So I think I should
be able to send this sort of communication over "Virtio Wayland",
without requiring any changes to the communications being channeled. I
just had this idea, so it's entirely possible it won't work out, but I
think it's a neat unexpected reuse of a cool technology.
Infrastructure
--------------
The web interface for the Spectrum mailing lists has been upgraded from
Django 1.11 (which is now EOL) to Django 2.2 (current LTS; Nixpkgs
default). I sent this upstream as Nixpkgs PR #84896.
Additionally, spectrum-os.org. now has an SPF header, which I thought
was already there but apparently wasn't. This should help with mailing
list deliverability.
That's it for this week. Feel free to reply with any comments or
insights, either on the content or the format. I'll try to be back with
another development update next week.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next reply other threads:[~2020-04-12 16:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-12 16:30 Alyssa Ross [this message]
2020-04-12 22:19 ` Amanjeev Sethi
2020-04-19 22:25 This Week " Alyssa Ross
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d08cll9m.fsf@alyssa.is \
--to=hi@alyssa.is \
--cc=devel@spectrum-os.org \
--cc=discuss@spectrum-os.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).