[Nix-dev] Using Nix to build embedded linux firmware
Lluís Batlle i Rossell
viric at viric.name
Mon May 21 12:05:37 CEST 2012
On Mon, May 21, 2012 at 12:48:25PM +0400, Michael Raskin wrote:
> >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.
> >
> > The size is only a problem for small devices which
> > have a very limited amount of flash memory available.
> > Those devices might also not be able to execute
> > Nix expressions because their CPU power and main memory is
> > limited. It seems Nix wasn't really designed to
> > run in resource-constrained environments.
>
> You may need to patch stdenv, though, as you could need a smaller libc
> and busybox instead of glibc and coreutils. There is some support for
> that, but you'll likely need to tune it for your use case.
I wanted to do some work towards minimizing the amount of binaries deployed, but
the nanonote has 2GB of NAND, and so I did not worry much. :)
We could have some optional deployment of manpages, etc.
> >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?
>
> Technically, it would be possible to have a mirror nix store on a normal
> computer and sync device with it (as path contents should not change,
> you need only to copy new paths and delete obsolete ones, not change
> anything).
That's what the 'tonano' script does:
http://viric.name/cgi-bin/nanonixos/artifact/ddf64d608c252cd3e655c56fe37228701bda7ef4
> >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 doesn't support this. You would probably have to generate them and
> then create a minimal tool to run these scripts on configuration
> changes. In a sense, NixOS is an example of such a tool. Note that it
> gets no support from Nix per se for configuration activation.
Nanonixos is a simpler (less lines, less flexibility) example of such a tool too.
In fact I'd be interested to be able to deploy a full nanonixos to those
broadcom-mips-based routers, but I've not cared enough about making small store
paths still.
(I wrote the previous letter without having read this)
Regards,
Lluís.
More information about the nix-dev
mailing list