| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
It makes more sense to default to a VM that doesn't do networking, and
so will actually work out of the box.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
| |
Before this change, a clean release/live "make -j4" had a median
runtime of 85 seconds. Now, it's 37 seconds. That much of a
reduction in iteration time is worth the extra complexity.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
| |
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
| |
This way, we don't have to worry about them confusing Nix, or the
lockfiles ending up in git.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
| |
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
| |
Otherwise, cloud-hypervisor won't be able to bind to the path and will
fail to start.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
| |
This makes testing cloud-hypervisor annoying, as it requires
privileges, and we have QEMU around anyway if we need to test
networking.
I have not made the corresponding change in vm/sys/net, because
there's not much point testing that VM without any network devices.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our image Makefiles are either used for interactive development in a
nix-shell, or as part of a Nix build of Spectrum. In neither of these
cases is the two step "make; make install" process useful like it is
for packages, because one image from Spectrum somewhere on the
development system isn't something it ever makes sense to do.
By removing the separation between building and installing, and
creating the final output directly in its destination, we can save
some copies of very large files, which should save seconds in each
build, even for the smaller components.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
| |
This was widely used when each component was responsible for filtering
out its own Nix files, but now that's centralised, all these bindings
can be cleaned up.
Fixes: 0149885 ("nix: centralise source cleaning")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
| |
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20221010232909.1953738-9-hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
| |
Not all VMs will even have networking! So it makes more sense to put
waiting for the network in the application-specific part.
The "listen" and "wait" scripts are copied from the host system.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20221010232909.1953738-8-hi@alyssa.is>
|
|
|
|
|
| |
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20221010232909.1953738-7-hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can simplify our Makefiles a bit by moving some things into a
library file. So far, I've done this for non-component-specific
macros, and inference rules.
Some tar2ext4 rules used a temporary file for the tar2ext4 invocation,
and then moved the file into place when it was done, to prevent a
half-built image sticking around if tar2ext4 died. According to
POSIX, make should clean up any targets that didn't finish building if
it's interrupted, so we should only end up with a half-built image if
tar2ext4 crashes, e.g. due to running out of disk space. I think we
should just ignore that possibility, since otherwise we'd have to
write annoying make rules using temporary file names for every target,
and if it does happen recovery is just a make clean away.
With this, I've also made a small reorganisation. I got rid of the
"nix" directory and created a "lib" directory, where I put
eval-config.nix and the new common.mk file, since both are library
code. checks.nix isn't really a library though, so I moved it into
the "release" directory, since the only reference to it is in
release.nix.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I introduced the global src attribute, I broke custom
configurations, since they wouldn't be passing that key in, and nor
should they. To allow for non-customisable globals like src, we need
to separate them from config. Here, I've modified eval-config.nix to
take a callback, so that it can provide multiple attributes, and
handle command line arguments itself so that doesn't need to be in
every entry point any more. This gives us an interface similar to the
NixOS module system's, where a variety of globals are available that
can be pulled out of the passed attribute set as required, but with
the additional advantage that files are usable directly from
nix-build, and support command line arguments.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Fixes: 0149885 ("nix: centralise source cleaning")
|
|
|
|
|
|
|
|
|
| |
This was getting very repetitive. Having a single copy of the sources
shared between builds will also save on store space, and means we
don't need to support overriding the path to the scripts directory in
Makefiles.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
|
This patch introduces a generic application VM image. It mounts a
filesystem containing the application, and then launches a "run"
script on that filesystem to start the application. The Nix store on
the application filesystem is overlaid onto the generic Nix store, so
shared paths don't have to be duplicated in the application
filesystem.
The "appvm" image is part of the Spectrum system — it lives on the
root filesystem, not the user data partition. Users of course have
the choice not to use the built in image if they don't want to, but
this gives us a default to use for future features like starting VMs
at runtime.
Individual application VMs are now defined in a single Nix file each,
using a VM builder function. I expect this is how Nix-based VMs would
be defined in the user data partition, and then built with Nix into
Spectrum VM configurations.
The new top-level vm-lib directory is intended to be copied into user
Nix expressions that build VMs, and therefore has to be usable
standalone. User-defined VMs should not do any path deduplication
with the system-provided base VM, so that the two can independently
update Nixpkgs. But for VMs that are part of the system (which I
consider the pre-built VMs to be, even though they're currently on the
user data partition), we can safely deduplicate paths that we know to
be present in the base image. So they go through vm/make-vm.nix,
which is a wrapper around vm-lib/make-vm.nix that does this
deduplication.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20221009114036.463071-7-hi@alyssa.is>
|