patches and low-level development discussion
 help / color / mirror / code / Atom feed
From: Alyssa Ross <hi@alyssa.is>
To: devel@spectrum-os.org
Cc: Alyssa Ross <hi@alyssa.is>, Jean-Philippe Ouellet <jpo@vt.edu>,
	Michael Raskin <7c6f434c@mail.ru>
Subject: [spectrum-devel] [PATCH www] design: state subdirectories, not block devices
Date: Wed, 16 Oct 2019 20:28:45 +0000	[thread overview]
Message-ID: <20191016202845.21132-1-hi@alyssa.is> (raw)

Conversation on IRC has convinced me that this is the right thing to
do after all:

<https://logs.spectrum-os.org/spectrum/2019-10-15#1571117332-1571144389;>
---
Jean-Phillipe, I'd be curious to hear your thoughts on the above
discussion, since you recommended block devices to me when we talked.

 design.html | 29 ++++++++++++++---------------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/design.html b/design.html
index 4b96a41..dc14cfe 100644
--- a/design.html
+++ b/design.html
@@ -43,23 +43,22 @@ one per application.
 Each virtual machine will be generated by
 a <a href="https://nixos.org/nix/">Nix</a> derivation, and will have a
 completely immutable root file system.  Persistent storage will be
-provided by virtual block devices, that arbitrary paths on the system
-can be mapped to from the host.  There may be other writable mount
-points inside the virtual machine, but these will not persist between
-reboots of the VM.  Using Nix to generate virtual machines allows them
-to be reproducibly built, rolled back, edited, and migrated as source
-code, rather than large, opaque virtual machine images.
+provided by mounting subdirectories of the global state directory into
+virtual machines.  There may be other writable mount points inside the
+virtual machine, but these will not persist between reboots of the VM.
+Using Nix to generate virtual machines allows them to be reproducibly
+built, rolled back, edited, and migrated as source code, rather than
+large, opaque virtual machine images.

 <p>
-Virtual block devices will also be defined in Nix, and block devices
-and applications will be <var>m</var>:<var>n</var>.  Some virtual
-machines may have no persistent storage, or even write access to a
-disk, at all.  In other cases, it might be desirable for multiple
-applications to be able to access the same device, such as a local
-mail store being shared by two mail clients.  Other resources and
-permissions, such as network cards and USB controllers, will similarly
-be defined in Nix.  There are three logical sections for the Nix
-configuration -- applications, which are just packages, resources
+State directories and applications will be <var>m</var>:<var>n</var>.
+Some virtual machines may have no persistent storage, or even write
+access to a disk, at all.  In other cases, it might be desirable for
+multiple applications to be able to access the same device, such as a
+local mail store being shared by two mail clients.  Other resources
+and permissions, such as network cards and USB controllers, will
+similarly be defined in Nix.  There are three logical sections for the
+Nix configuration -- applications, which are just packages, resources
 (virtual or physical devices), and <i>application instances</i>, which
 are mappings between applications and accessible resources.  This
 structure allows users to have multiple instances of the same
--
2.23.0

             reply	other threads:[~2019-10-16 20:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 20:28 Alyssa Ross [this message]
2019-10-16 21:33 ` [spectrum-devel] [PATCH www] design: state subdirectories, not block devices Michael Raskin
2019-10-16 23:15   ` [spectrum-devel] " Alyssa Ross
2019-10-17  7:47   ` Michael Raskin
2019-10-17 11:36     ` Alyssa Ross
2019-10-17 12:09     ` Michael Raskin
2019-10-18 18:51       ` Alyssa Ross
2019-10-18 18:56       ` 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=20191016202845.21132-1-hi@alyssa.is \
    --to=hi@alyssa.is \
    --cc=7c6f434c@mail.ru \
    --cc=devel@spectrum-os.org \
    --cc=jpo@vt.edu \
    /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).