From e0bd64b80fcbe098a6224b59e62b5a1063bb4871 Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Tue, 28 Mar 2023 16:14:00 +0100 Subject: [PATCH] week source --- THOUGHTS.txt | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index 9900e1bb..ccf3adff 100644 --- a/THOUGHTS.txt +++ b/THOUGHTS.txt @@ -1233,3 +1233,142 @@ Sat Mar 18 18:02:26 GMT 2023 What if: we added derivations for "apply openwrt changes" as packages, which could then be called from the kernel derivation's extraPatchPhase? There could be one for generic and one for each openwrt targetop + +Mon Mar 20 18:40:53 GMT 2023 + +- kexec patch is sent to mailing list, keep an eye for replies +- watchdog +- ntp +- rebuild images for live devices +- can we build a static busybox with flashcp applet and scp it + to arhcive etc? +- [DONE] install mailman and hyperkitty on myhtic, create mailing list + +Tue Mar 21 22:59:54 GMT 2023 + +I haven't found a way to arm the watchdog before userland runs, which +would be really nice: although there's WATCHDOG_HANDLE_BOOT_ENABLED +and WATCHDOG_OPEN_TIMEOUT it doesn't seem to be sufficient, Maybe +those options work only when the hardware watchdog is already +armed. It might not be completely awful insofar as any failure to +mount root usually results in panic anyway, so provided we start +watching early in boot then there's not a big window for anything +to go wrong + +What should the watchdog service do? Ideally we want something that +"ratchets" : can be started in early boot and signals health as long +as the system is starting up, then once the system is in "steady +state" it stops pinging as soon as any part of that steady state +becomes unhealthy. This feels like a refinement for a much later +phase though. + +Maybe the health criteria might be +(sshd and lan services are running) or (time since boot < 120s) + +Thu Mar 23 00:11:23 GMT 2023 + +tftpboot and (kexecboot || flashable) have incompatible DTB-finding +strategies which is painful if you add both modules and then +expect tftp booting to still work + +Maybe we could patch the kernel to use some better strategy for when +to use/ignore the bootloader command line: e.g "only if it +contains the string 'liminix'". Could do this by patching +arch/mips/kernel/setup.c bootcmdline_init to + +if(strstr(arcs_cmdline, "liminix") == NULL) arcs_cmdline[0] = '\0' +and then defining CONFIG_MIPS_CMDLINE_DTB_EXTEND. The +bootloader command line then needs to specify only the +_additional_ parameters that weren't in the DTB + +(later: that turned out to be quite straighforward) + +Fri Mar 24 23:45:12 GMT 2023 + +- add ntp support +- [DONE] expose hydra to internet +- check MAC address weirdness? +- call Task 1 "done" + +Sun Mar 26 00:19:15 GMT 2023 + +Would be nice to have a flash.sh built in outputs.flashable + +Sun Mar 26 15:27:14 BST 2023 + +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 + +suppose: + +* modules add service functions to the config? then there's no +way to define a service while forgetting to import the module + +* we use the lib.types stuff for service function arguments + +* maybe we stop naming services.foo for every damn thing + +* but remember, s6 services do need unique names + + +imports = [ ../modules/dhcp4 ]; + +services.dhcp4 = config.services.udhcp { + interface = lan.device; + options = { + foo = true; + bar = 42; + }; + depends = [ services.some_other_thing ]; +} + +modules/dhcp4 udhcp fn needs to define a type for its argument, then +use something like + + if arg_type.check def.value then res + else throw "The option value `${showOption loc}' in `${def.file}' is not a ${arg_type.name}.") + +(where def comes from I don't know yet) + +Tue Mar 28 10:44:40 BST 2023 + +we should reserve the name "service" for actual instantiated +services. This means we need a name for the functions that +make services. "class", "template", "fn", "maker", "factory"? +And a namespace name so they're not interleaved with real +services, which sort of suggests they are packages + +if we want to do services = { + foo = longrun { ... }; + bar = longrun { ... }; +} + +without repeating the `name` as an attribute of the longrun, +then longrun can't return a derivation: it has to return some +function that accepts `name` as a parameter. + +where services.a depends on services.b, at the time its builder is run +it needs to know what name s6-rc will use for service b + +maybe an s6 service definition should be an attrset not a derivation. + +maybe this is outside scope for phase 2 + +Tue Mar 28 13:22:06 BST 2023 + +Reading nixos/doc/manual/development/building-parts.chapter.md it +suggests to me that we should rename config.outputs to +config.system.outputs. The more general question here is whether it's +good to be augmenting a variable called "config" with all this +generated stuff that is patently not configuration - perhaps putting +it under a "system" key will keep it all in one place