From: "Amanjeev Sethi" <aj@amanjeev.com>
To: "Alyssa Ross" <hi@alyssa.is>, devel@spectrum-os.org
Cc: discuss@spectrum-os.org
Subject: Re: This week in Spectrum
Date: Sun, 12 Apr 2020 18:19:33 -0400 [thread overview]
Message-ID: <0d4404b7-3435-47c3-8281-8737a277648c@www.fastmail.com> (raw)
In-Reply-To: <87d08cll9m.fsf@alyssa.is>
I find these emails a nice read when I have time. I am perhaps not on the devel list (not a devel).
On Sun, Apr 12, 2020, at 12:30 PM, Alyssa Ross wrote:
> 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.
>
> Attachments:
> * signature.asc
next prev parent reply other threads:[~2020-04-12 22:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-12 16:30 Alyssa Ross
2020-04-12 22:19 ` Amanjeev Sethi [this message]
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=0d4404b7-3435-47c3-8281-8737a277648c@www.fastmail.com \
--to=aj@amanjeev.com \
--cc=devel@spectrum-os.org \
--cc=discuss@spectrum-os.org \
--cc=hi@alyssa.is \
/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.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
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).