[Nix-dev] Using Nix to build embedded linux firmware

[Nicolas Pierron]

Hi,

On Mon, May 21, 2012 at 10:11 AM, Felix Lange <fl at travelping.com> wrote:
> A closer look at Nix has revealed some questions:
>
> Cross Compilation
>        There seems to be some work in the nixpkgs tree that deals with
>        cross builds (pkgs/top-level/release-cross.nix). It would be interesing
>        to hear from the people who are behind this. Are cross
>        builds alive and supported?

I have been using some of them recently, to cross-build the Javascript
engine of Firefox.  So even if you cannot cross-build perl yet, you
can still use perl to bootstrap and configure your builds.

Nix packages are design such as we can distinguish between the host
dependencies and the build dependencies.  So the same nix-expression
can be used for both the build version and the host version.

The usual approach of package manager is to maintain a separated set
of packages for building the host versions.

> Nix's binary size and runtime requirements:
>        Our usual size limit for images is 8MB compressed. With an image
>        that small, we need to be really picky about what goes in
>        and what doesn't. Quick measurement shows that Nix + libraries
>        take ~10MB on disk. AFAIK, Nix also requires the C++ STL.

We have almost a similar issue with our bootstrap tools, even if the
size is not as important we try to reduce to the minimal set of
programs needed for bootstrapping Nix packages, without any host
system.

One similar thing that I have been working on recently is the
cross-bootstrap tools which implies cross-compiling the tools needed
for bootstrapping Nix packages on another device which already has Nix
installed.

I am biased, but I really love to be able to build and *test*
cross-bootstrap-tools by using Nix feature to delegate jobs to another
computer with a different architecture.

For your limited use case, I won't recommend to embedded Nix on the
device because you cannot compile on the device.  What you seems to
need is limited to the update/rollback constraint which is done by
replacing a symbolic link (filesystem?) and running a generated
script/program (called activation).

> Remote installation of packages:
>        As a follow-up thought to the last one, would it be possible
>        to update an installation remotely, with only a very limited set of
>        tools being present? I've looked at Disnix, and the README says
>        that all target hosts need to have Nix (and Nixpkgs) installed,
>        which is unfortunate but understandable given its intended
>        use case (server/cluster deployment).
>
>        The Nix store file structure seems simple
>        enough to allow remote management. Is this correct?

This is seemes correct to me.  If you don't plan to have Nix on board,
you can just maintain the closure of the wanted systems on the remote
and remove everything which is not listed in the closure of the
systems.

Nix can generate such closure, and Hydra (the buildfarm) can even be
used to generate them.

> Configuration changes:
>        System configuration (networking, services...) is not part of Nixpkgs
>        but is kept in the NixOS tree. This is good, because we have very
>        specific needs in terms of network configuration and implement
>        it ourselves anyway.
>
>        How does Nix handle pre/post upgrade scripts? As far as I understand,
>        the Nixpkgs tree only contains build instructions, any output is created
>        at compile time.

Nix does provide post-install script because we want to have
deterministic and isolated results, which is the key of the
reproducibility and thus the rollbacks.

Each time NixOS is started it does not assume any setup of the system
and start creating/upgrading the system.  In case of dynamic data (as
opposed to static packages/configuration), they can be updated by
using a migration script if data are already present on the system.
This system is used by Hydra (the buildfarm) to update the database
schema.

The hic here is about rollback.  Your tools have to know how to revert
the schema of your dynamic data.  Without such abilities, Nix
rollbacks are useless when the schema is updated.

Our current activation script is a shell script, but I guess you can
cross-compile a small generated binary to do the same if needed.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/