[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