[Nix-dev] NixOS: hardware based configuration.

[Nicolas Pierron]

On Sat, Jul 26, 2008 at 03:58, Marc Weber <marco-oweber at gmx.de> wrote:
> The computer setups would take some arguments as well:
> Eg if you have a nvidia graphics card you can choose which driver to
> use..

Yes, devices may be parametrized by the software configuration like
kernel settings.

I have started to write something for the Go7007 encoding, which give
me the following result:

.----------------- Go7007.nix
| this:
|
| let
|   wis_go7007 = pkgs:
|     (this.boot.kernelPackages pkgs).wis_go7007;
| in
|
| {
|   boot = { extraModulePackages = pkgs: [ (wis_go7007 pkgs) ]; };
|   environment = { extraPackages = pkgs: [ (wis_go7007 pkgs) ]; };
|
|   services = {
|     udev = {
|       addFirmware = pkgs: [ "${wis_go7007 pkgs}/firmware" ];
|       addUdevPkgs = pkgs [ (wis_go7007 pkgs) ];
|     };
|   };
| }
`-----------------

I have not tested it yet.  This nix expression is a function which
expect to have a "this" attribute on the final set of the
configuration in order to retrieve the ".boot.kernelPackages"
attribute.  The "this" argument can lead to infinite recursion but
have the advantage to represent the complete configuration of the
computer.

The idea is to replace the function addDefaultOptionValues (pkgs.lib)
by the following functions:

  mergeOptionSets = defs: optsList: mergeAttrs optsList //
    builtins.listToAttrs (map (defName:
      { name = defName;
        value =
          let
            defValue = { merge = mergeDefaultOption; } //
              builtins.getAttr defName defs;
            optValues =
              map (opts: builtins.getAttr defName opts)
                (filter (opts: builtins.hasAttr defName opts)
                  optsList);
          in
          if typeOf defValue == "option"
          then
            # `defValue' is an option.
            if optValues == []
            then defValue.default
            else defValue.merge optValues
          else
            # `defValue' is an attribute set containing options.
            # So recurse.
            if optValues == []
            then mergeOptionSets defValue []
            else mergeOptionSets defValue optValue;
      }
    ) (builtins.attrNames defs));

which does the same as the previous function with a set of
configurations.  It merges configurations with the "merge" function
defined in the option definition.  If no "merge" function is defined
the merge operation is handled by the the function
"mergeDefaultOption".  This default merge function concatenate lists
and sets even if they are returned by function ( I love laziness with
introspection ).

  mergeDefaultOption = list:
    if list != [] && tail list == [] then head list
    else if all __isFunction list then x: mergeDefaultOption (map (f: f x) list)
    else if all __isList list then concatLists list
    else if all __isAttrs list then mergeAttrs list
    else throw "Default merge method does not work.";

By the way, the following function is very interesting to merge of
enable options.

  mergeEnableOption = fold logicalOR;


> I guess in the long run we should try writing something like Xorg
> has: Having a script/ program which can guess your hardware and
> create a system configuration based on that (or a pc-description you're
> proposing. This would be even more generic and more useful (if it works)
> So each device should have a derivation called
> recognizeMyself = scanPICfor "xy"; or such.. (you get what I mean)

Yes, something like:

identify = scanPCIfor (device:
  if device.name == "..."
  then {...}
  else null
);

with a scan.nix nix-expression which will do a filter over all devices
containing a non-null identify attribute.

> This would help a lot and would serve as documentation (what works) and
> implementation at the same time.. Not yet working hardware could be
> documented as TODO's or such.
> Just curious wether we should separate the os nixos from hardware
> configuration by adding a new repo trace/computer-configs or such

May be we should put this inside trace/configurations (even if the
repository name is no longer trace).

> Another config would be qemu-with-sound-and-network or such ?

Yes, as this could be interpreted as a device, there is no reason to
omit it because this may interest a lot of people.

-- 
Nicolas Pierron
- If you are doing something twice then you should try to do it once.