[Nix-dev] New arm platform: qemu-system-arm

[Nicolas Pierron]

On Sun, Nov 8, 2009 at 22:24, Lluís Batlle <viriketo at gmail.com> wrote:
> some times I mentioned that for arm devices, we would need in nixos
> some way of setting the platform where the OS will run, and not only
> the processor and the kernel (as in builtins.system).

may be such things could be separated and we can add more information.

all-packages.nix arguments:

{ cpu ? builtins.cpuInfo
, platform ? "pc"
, kernel ? builtins.kernelInfo
, pci ? builtins.pci # similar to lspci -vvvv
, system ? "${cpu.name}-${platform}-${kernel.name}"
, ...
}:

Adding this as argument will allow packages to assert specific terms:

assert pkgs.lib.elem [ "i686" "x86_64" ] cpu.name;
assert pkgs.lib.elem [ "linux" ] kernel.name;

instead of joined comparisons:

assert pkgs.lib.elem [ "i686-pc-linux" "i686-unknow-linux"
"x86_64-pc-linux" "x86_64-unknow-linux" ] system;

Moreover, this give us more control of specific optimization for
people who want to spend time on compiling everything.  Thus instead
of having MAKE_FLAGS like Gentoo, we can derive the optimization
(kernel config, compilation options, ...) for the targeted computer.

> I did some hack into nixpkgs/stdenv-updates to get that, and I
> considered the grub platforms to be 'pc', and then I have two arm
> platforms: sheevaplug and qemu-system-arm versatilepb (which I named
> 'versatileARM').
>
> I don't know how far it has to be extended, but the actual scheme (the
> platform attribute set in nixpkgs) works for my needs, and at least
> expresses the minimum information the rest of the nixos/nixpkgs system
> needs:
> - how to build the kernel
> - how to build the initrd
> - how to prepare the boot loader

Specialization is a deadly problem in your case, but it can be
extended to offer more optimization.  I don't think there is any need
to make it full of things yet.  What we should do is providing a way
to add things to it.  Thus the nixpkgs arguments are not a good
solution because you will have to change every files arguments, like
nixos/default.nix, nixos/lib/eval-config.nix and all-packages.nix ...

Thus I fill like builtins.system should contains the kernel, the cpu
and the platform.  Thus

builtins.system == rec {
  cpu = ...;
  kernel = ...;
  platerform = "pc";
  name = "${cpu.name}-${plateform}-${kernel.name}";
}

and changing the platform correspond as overriding the builtins.system:

builtins.system.override {
  platerfom = "unknow";
}

> Now a user can use its configuration.nix to state, for example:
> nixpkgs.config = {
>      packageOverrides = pkgs: with pkgs; rec {
>        platform = platformVersatileARM;
>      };
> }

I don't like adding "platform" inside all-packages.nix, because this
let us fell that platform is a derivation.  I'll prefer seeing it
inside the arguments or embedded inside builtins.system.

> Those who follow stdenv-updates, feel free to comment on that. I don't
> doubt you may have better ideas to reflect the 'platform' information
> properly for nixos. Pierron, any suggestion as a nixos module? How
> much of that information in 'platform' should be in nixpkgs, and how
> much in nixos?

NixOS is the configuration environment around the NixPkgs.  NixPkgs
contains packages which have to be setup for the system (including the
platform).  NixOS do not modify builtins.system, but it can modify
options based on its content:

----------
{pkgs, ...}:

with pkgs.lib;

mkIf (builtins.systems.plateform == "pc") {
  boot.loader.grub.enable = mkDefaultValue true;
};
----------

Thus you can modify default values based on the platform to add less
configuration pain for people who have the same platform as you.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
Richard Feynman - I think I can safely say that nobody understands
quantum mechanics.