commit 2c10790a6d9cb0c27afa4ac11deb522240d7cacc
parent 571adf84c0077009b29221a4b8006b794833bef6
Author: Daniel Barlow <dan@telent.net>
Date: Sun, 9 Jun 2024 11:19:38 +0100
think
Diffstat:
| M | THOUGHTS.txt | | | 83 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 83 insertions(+), 0 deletions(-)
diff --git 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.
