From fc723b9a354bb6f61098410544758e5d0e3e5813 Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Tue, 16 Apr 2024 18:59:01 +0100 Subject: [PATCH] think --- THOUGHTS.txt | 151 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index 6606706..cacd705 100644 --- a/THOUGHTS.txt +++ b/THOUGHTS.txt @@ -4412,3 +4412,154 @@ it can know what to update Maybe config.filesystem should specify /etc/s6-rc/compiled.new and something in early boot could symlink /etc/s6-rc/compiled to it + +Sat Mar 30 18:41:14 GMT 2024 + +soft restart doesn't restart services that are invoked by trigger, +because it has to do -p -u default so that it prunes services that +were in the old config but not the new one. Ideally we need somehow +to notify the trigger that it should respawn its service. Maybe +we could add triggers to the force restart list, if there's a way +to detect which they are? don't want to do it by adding files in +the service state directory if there may be oneshot triggers. Can +there be oneshot triggers? + +The hashes file is built when we build the service database, so we +could easily(?) add something in there to mark services that +need poking whenever there's a restart. It's not perfect because the +triggered services will be bounced unnecessarily, but remember that +the alternative is a reboot ... + +Mon Apr 1 00:18:50 BST 2024 + +i) I don't know if digressing into remote log shipping is a tangent or +an important part of making services work well. + +ii) Should there be a single "machine state" value for all of the +trigger services to reference, or is it better that each trigger +service has its own private state, or (third option) one state +per "state source"? We previously handwaved that a state source +is a service + +services.addmember = services.udev.watch { + match = { + SUBSYSTEM = "net"; + ID_PATH = "pci-0000:04:00.0"; + ATTR.operstate = "up"; + }; + + service = oneshot { + up = "ip link set dev $dev master $(output ${primary} ifname)"; + down = "ip link set dev $(output ${member} ifname) nomaster"; + }; +} + + +Tue Apr 2 19:55:25 BST 2024 + +We could do a test script for udev usb disk mounting, which uses the +qemu monitor to add/remove a disk. + + +./result/run.sh --flag -device --flag usb-ehci,id=xhci --flag -drive --flag if=none,id=usbstick,format=raw,file=./stick.img + +(qemu) device_add usb-storage,bus=xhci.0,drive=usbstick + +Fri Apr 5 17:11:46 BST 2024 + +1) write a fennel thing that reads from the udev rebroadcast socket +2) and can check sysfs for state +3) set up mdevd in liminix + + +Sat Apr 6 13:23:02 BST 2024 + +I wonder if we could replace preinit with an execline script? One for +the TODO stack + + +Sun Apr 7 14:03:29 BST 2024 + +1) we want to know what messages are sent from mdevd under various circumstances + - actually, right now the only relevant circumstances are updown and inout + +2) we might get a wider variety of messages from real hardware? + +3) if we log the raw messages, pref. with timestamps, then we can +write tests for the parsing + + +therefore: write a program that opens the netlink socket and logs +all data received + +---- + +what's the minimum we need here? we need the inout test to open a +uevent socket and use uevents to update some state that says whether the +backup drive is plugged in + +rather awkwardly, uevents don't have filesystem labels. so we also need +to run blkid to find the label of each partition, and ideally we do this +while the partition is present, not each time we get an event for it. + +We have DEVNAME, DEVTYPE, SUBSYSTEM to indicate that a filesystem of interest +may be present, we should use that as a trigger to scan any known + + + +add@/devices/pci0000:00/0000:00:13.0/usb1/1-1/1-1:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 +ACTION=add +DEVPATH=/devices/pci0000:00/0000:00:13.0/usb1/1-1/1-1:1.0/host0/target0:0:0/0:0:0:0/block/sda/sda1 +SUBSYSTEM=block +MAJOR=8 +MINOR=1 +DEVNAME=sda1 +DEVTYPE=partition +DISKSEQ=2 +PARTN=1 +SEQNUM=1528 + +Some disks on loaclhost and noetbook have PARTNAME field - I assume +this is because they're GPT disks. Would it actually be better to use this +field than grovelling for filesystem label? + +Tue Apr 9 21:07:50 BST 2024 + +Having waited for the appropriately labelled disk to appear, we then +also have to communicate its path to the service that mounts it + +- create a symlink +- or use an instanced service + +Creating a symlink will be fine if we can pass the symlink name as +a param to fswait + +Wed Apr 10 20:53:48 BST 2024 + +We think that fswait will evolve into a more general +waiting-for-uevents tool. Maybe we could provide the matchers on the +command line: + +waituevent -l /dev/volumes/backup-disk -s mount-srv devtype=partition partname=backup-disk + +Thu Apr 11 23:09:43 BST 2024 + +lcommit d3a2e3a4cb80b631df2ab79d463c2c4d1adef37b +commit 4a58cf9335116ce673fcf08f70f3bca921a4c9ad +commit afca6d4b63dd39062f02827b3c29e16904770216 + +Sun Apr 14 19:50:27 BST 2024 + +how to get this on to main: + - make uevent-watcher package (it's fswait renamed) + - make mount service use it + - module for mdevd + - add nellie (generalise for other netlink uses w/params pid/family/groups) + +Mon Apr 15 19:59:43 BST 2024 + +plan: + +introduce uevent-watcher command, update test to use it + +make mount service use it