patches and low-level development discussion
 help / color / mirror / code / Atom feed
From: Michael Raskin <7c6f434c@mail.ru>
To: alyssa.ross@unikie.com
Cc: vadim.likholetov@unikie.com, devel@spectrum-os.org
Subject: Re: Developer-friendliness
Date: Tue, 06 Dec 2022 23:05:02 +0100	[thread overview]
Message-ID: <E1p2fvP-00046m-5g.7c6f434c-mail-ru@smtp46.i.mail.ru> (raw)
In-Reply-To: <20221206211436.d7qnzgfkaijjhcz3@x220>

>> Well, one could have VM generator functions, so that you can easily
>> generate a development-like VM or a reasonable-setup like VM or minimal
>> VM (without D-Bus etc.), and so the developers can just use the dev
>> version and always get the good stuff included?
>
>Yes, that's true.
>
>Just as a quick refresher, currently if you want to make a Spectrum VM,
>these are your options:
>
> - Lay out the VM configuration directory manually in the user data
>   partition, and bring your own kernel/rootfs.
>
> - As above, but use the rootfs and kernel in /usr/img/appvm.  These aim
>   to provide a "standard" environment that can be shared between
>   application VMs, so it comes with mesa, and in future virtio-gpu set
>   up, as well as D-Bus, PipeWire, etc.  It mounts a second block device
>   that contains your application, as well as any dependencies not
>   included in the base image, and then runs your application from
>   there.  This way, big stuff like mesa only has to exist once on disk.
>
> - Create an application VM that uses /usr/img/appvm with Nix, using
>   vm-lib/make-vm.nix.

Yes, sorry, I have still not tried all this (I am going to avoid Wayland
as the main UI as long as practical, and I am not going to commit enough
time to Spectrum-adjacent things to make it worth your time to ask how 
would I set up things for Spectrum-like isolation of single things into
Weston-inside-Xorg or whatever on host).

>So what we're missing is a way to create, with Nix, a VM that isn't
>based on the /usr/img/appvm "template".  The reason we don't currently
>have such a function is that I don't think it's clear yet how it should
>work — what should be customisable, what should be part of the base
>image vs. not, etc.?  For a while, how make-vm.nix should work was
>similarly unclear, which is why it only recently came into existence.
>After I'd manually created my third or so application VM, it became
>clear what could be part of the base image, and what had to be
>customisable.  Currently, we only have one VM in the tree that doesn't
>use the /usr/img/appvm template, netvm.  Once we have more, I think
>it'll be easier to evaluate how a more minimal VM builder function
>should work.

Hm, I would say that I have a good experience solving such a problem
with a Nixpkgs-overlay-like structure, i.e. a makeExtensible with all
possible tunables defined as attributes, and then more complex data
structures built out of them, as well as packages for the things.







  parent reply	other threads:[~2022-12-06 21:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-04 22:42 Firefox appVM patches and appVM refactoring Vadim Likholetov
2022-12-06 11:42 ` Alyssa Ross
2022-12-06 13:56   ` Vadim Likholetov
2022-12-06 15:18     ` Alyssa Ross
2022-12-06 15:20 ` Alyssa Ross
2022-12-06 15:57   ` Vadim Likholetov
2022-12-06 17:10     ` Alyssa Ross
2022-12-06 20:12       ` Vadim Likholetov
2022-12-06 20:25         ` Alyssa Ross
2022-12-07  7:41           ` vadik likholetov
2022-12-06 20:19       ` Vadim Likholetov
2022-12-06 20:31         ` Developer-friendliness Alyssa Ross
2022-12-07  7:46           ` Developer-friendliness vadik likholetov
2022-12-06 20:59         ` Developer-friendliness Michael Raskin
2022-12-06 21:14           ` Developer-friendliness Alyssa Ross
2022-12-06 22:05           ` Michael Raskin [this message]
2022-12-07  8:04       ` Firefox appVM patches and appVM refactoring Ville Ilvonen
2022-12-07 11:09         ` vadik likholetov

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=E1p2fvP-00046m-5g.7c6f434c-mail-ru@smtp46.i.mail.ru \
    --to=7c6f434c@mail.ru \
    --cc=alyssa.ross@unikie.com \
    --cc=devel@spectrum-os.org \
    --cc=vadim.likholetov@unikie.com \
    /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).