From 492317623d2d142532109a73cc3850d7f29d73e0 Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Thu, 13 Jul 2023 11:54:50 +0100 Subject: [PATCH] more thoughts about modules --- THOUGHTS.txt | 103 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index 77701c0..e8fa878 100644 --- a/THOUGHTS.txt +++ b/THOUGHTS.txt @@ -1901,3 +1901,106 @@ Thu Jun 22 23:58:58 BST 2023 Looks like we're missing at least one kernel config setting for nftables. Would this be a good time to do a derivation for building kernel modules? + + +Sun Jul 9 21:21:17 BST 2023 + + +Tue Jul 11 22:10:17 BST 2023 + +- s6 cheatsheet, find or write +- could we have > 1 module add to services.default? +- odhcp should parse values from environ and write more files, to save readers + from parsing it +- pkgs.liminix, who knows what thats for any more? +- interface.device, as a general rule, doesn't work because the + device name may be known only at runtime (e.g. for ppp) +- iperf +- figure out wifi regdomain + +Tue Jul 11 23:01:59 BST 2023 + +We can make services depend on kernel modules, however not on bakedin +kernel config + +[from March: "Let's think about services and modules."] + +Module ++ can change global config + * add users, groups etc + * change kernel config + * change busybox config ++ well-typed parameters +- is a "singleton": can't have the same module included twice + with different config. e.g. can't have two hostap modules running on + different wlan radios. +- can't express dependencies: a depends on b + +thought I had then was: modules provide services. requiring the +ppp module causes config.services.ppp to exist, so you can + +services.default = [ + (config.services.ppp { + tty = "17"; + baud = "57600"; + secrets = blah; + }) + ... +] + +this might work. also though we should find out how to do type checking on +service params + +Wed Jul 12 23:23:02 BST 2023 + +https://github.com/NixOS/mobile-nixos/pull/406 // why mobile nixos uses +mobile.outputs instead of system.build + + suggests that system.build may not be a thing to blindly emulate + +if a service is a derivation should we expect to want to be able to call +it with .override? maybe we want to override the package containing the +daemon it runs. How do we best pass service config as well? + +Maybe a service template is a function that returns a derivation + + +imports = [ ./modules/pqmud.nix ]; +services.mud = system.services.pqmud { + realm = "A deep cavern"; + port = 4067; + users = import ./allowed-users.nix; + # etc etc +}; +services.mudBeta = let mud = + system.services.pqmud { + realm = "A very deep cavern"; + port = 4068; + users = import ./allowed-users.nix; + }; + in mud.overrideAttrs { pqmud = pkgs.pkmudLatest; }; + +so we have + +config.system.services # services provided by modules +config.system.outputs # build artefacts of various types + +the services provided by a module must be introspectable in some way +so that we can compile a list of service options per module + +service parameters are defined using the module type system. +Something like this? + +# mud.nix + +system.services.pqmud = args : + let t = { + name = mkOption { type = types.str; }; + realm = mkOption { type = types.str; }; + port = mkOption { type = types.port; default = 12345; }; + users = mkOption { type = types.any; }; + }; + in assert isType (submodule { options = t; }) args; longrun { + inherit (args) name; + run = "${pkgs.pqmud}/bin/pqmud --port ${port} ....." + };