From 2c10790a6d9cb0c27afa4ac11deb522240d7cacc Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Sun, 9 Jun 2024 11:19:38 +0100 Subject: [PATCH] think --- THOUGHTS.txt | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index f80065e..c97d68e 100644 --- a/THOUGHTS.txt +++ b/THOUGHTS.txt @@ -4985,3 +4985,86 @@ and the attrs tests after even that, because they're that mich slower. Let's change it up. The database contains kobjects not events. A kobject knows its mountpoint as well as its path, and implements the attr and attrs methods + + +Sun Jun 2 20:58:47 BST 2024 + +we have a new uevent-rule service that can start/stop its controlled +service based on uevent fields and sysfs attrs for the corresponding +device/any ancestor of its sysfs path + +we need +- a way of starting _dependent_ services of the controlled service: + we want to activate that whole sub-branch of the dependency tree + +- a way to not attempt to start dependents of the controlled service +at boot time: we don't want to put them in the default bundle if +they depend on stuff that's part of the default service set. + +what happens when a service depends on _two_ controlled services? +we want to start it only when _both_ of them are up. That discourages +any idea of creating a bundle for each controlled service and its +dependants + +Tue Jun 4 19:07:44 BST 2024 + +we have to do it at runtime. I think we can add a file in the service +directory to identify that it's triggered (i.e. only run in response +to an event, we could use better terminology here( + + +for s in the reverse deps of $triggered + unless any? (s1: { s1.triggered && s1.down } ) + s.dependencies + start s + +we can do this in ci, maybe adapt the inout test + +two triggered services, A with a uevent that does happen +and B which doesn't + +two dependent services; C depends on A only and D on A+B. + +each should write an output +we check that the output from C is present but not the one from D + + + +Tue Jun 4 22:22:20 BST 2024 + +We can't have dependencies of triggered services unless we expose the +triggered service instead of the watcher from the module that sets up +uevent-watch. otherwise the user will be declaring their dependencies +on the watcher and they will start when the watcher does. We need to +invert it. + +Bother. + +services.mount-foo = oneshot { + name = "blah"; + up = "mount /dev/disk/by-partlabel/mydisk"; + runCondition = conditions.sysfs { + terms = { partlabel = "blah"; }; + symlink = "/dev/disk/by-partlabel/mydisk"; + } +} + +To process this, we need to + +- remove it from the default bundle +- create a service that _is_ in the default bundle which + starts this one when runCondition is true + + +How would it look for service conditions other than uevents + +Thu Jun 6 21:49:10 BST 2024 + +runCondition can be a function that accepts the service to be +watched and returns a service that does the watching. The +derivation calls this function and makes the watched service +depend on the watcher. + +When adding services to the default bundle (wherever that happens, I +no longer remember) we need to check if the service has a controller +and add that instead of the service itself.