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

[Lluís Batlle i Rossell]

On Mon, May 21, 2012 at 10:11:32AM +0200, Felix Lange wrote:
> Hi,
> 
> I am currently evaluating Nix and it's universe of tools
> for a company project and after playing with it for a while,
> I'd like to discuss my considerations with the list.
> 
> Our company, Travelping GmbH, is a producer of specialized telecommunications
> equipment. The firmware for our devices is based on a custom Linux
> distribution, TPLINO. In the project I'm working on, we're basically looking
> for a new underpinning of TPLINO. We've been working with OpenWRT
> for about 5 years now and there are some areas where it doesn't
> satisfy our requirements anymore.
> 
> Comparing to the alternatives provided by Yocto and Gentoo,
> the Nix package manager seemed particularly attractive
> for its ability to reliably generate whole system _configurations_
> and the advanced upgrade/rollback features.
> 
> 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?

Yes. A major problem we have is that we still don't cross-build *perl*, because
it looks like not trivial. OpenWRT in this respect has some in-svn big files
describing each system they cross-build too.

Therefore, one troublesome piece to cross-build is nix itself. But many other
programs cross-build fine.

I wrote most of the cross-building pieces, and I use them both for preparing
binaries for already-deployed OpenWRT systems, and also for full-prepared
systems (nanonixos for the nanonote).
http://viric.name/cgi-bin/nanonixos/doc/trunk/doc/home.wiki

> 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.
> 
> 	Has anybody run into similar issues before?

Nix evaluation still requires quite a lot of RAM. In the Nanonote (32MB of RAM)
I don't think I can't get evaluation far away.


> 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?

In nanonixos I use a very easy remote installation of packages. See
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.

Nanonixos supplies a bit of this, in a simple way.
Take a look of the files there:
http://viric.name/cgi-bin/nanonixos/dir?ci=0faacb2bb92031a5

Feel free to clone the repository too.

So as you see there is some work to do:
* perl
* nix cross-building with perl support (I think recent versions of nix don't
  cross-build anything at all, but we could do some effort for it)
* nanonixos is a very simple remote deployment of a systemv GNU/Linux. Could be
  made more fancy like nixos.

Regards,
Lluís.