| 18 Mar 2025 |
 Nick Cao | Here: https://github.com/linyinfeng/nixpkgs/commit/80be7b4c5c1842147b569fb50670952ba726d90c | 22:01:19 |
 ElvishJerricco | I feel like it'd be better to have a mkApply or something that just adds a finalization function to that priority layer | 22:02:38 |
| ElvishJerricco | Ok, I'm happier with this now: https://github.com/NixOS/nixpkgs/pull/375975 | 23:42:39 |
| ElvishJerricco | I made it possible to set / unset kernel modules as an attrset, with descriptions making it clear that this does not do blacklisting (though I made a similar change to blacklistedKernelModules). And I added a warning to the allowMissingModules description telling people they should disable individual modules instead. | 23:43:52 |
| ElvishJerricco | oh shit I have to document that type I factored out into lib now don't I | 23:44:26 |
| 19 Mar 2025 |
|  @jkxyz:matrix.org left the room. | 16:17:35 |
|  rappet changed their profile picture. | 23:12:01 |
| 20 Mar 2025 |
| ElvishJerricco | So this is interesting: https://github.com/NixOS/nixpkgs/pull/391329 | 06:39:13 |
| ElvishJerricco | I had assumed that this is covered by boot.kernel.sysctl. But I guess sysfs and sysctl do slightly different things? | 06:39:40 |
 @msanft:matrix.org | I thought that it's just a different interface to the same thing. | 08:09:04 |
| ElvishJerricco | Moritz Sanft: That's kinda what I thought but... I think that might be wrong? Seems like sysctl is for /proc/sys, not /sys, and apparently those are meaningfully different? | 08:32:58 |
| @msanft:matrix.org | Just learned that too. But it kind of makes sense. You don't find e.g. device info in /proc/sys, while you do in /sys | 08:52:08 |
 Ramses 🇵🇸 | Yeah, a lot of drivers expose things under /sys/class where you can write to files to configure stuff | 09:25:15 |
| Ramses 🇵🇸 | A lot of those things are only present when the device has been loaded though, so I feel that we'd need something more dynamic than a single systemd-tmpfiles invocation. I use path units myself to trigger writing to such files when they appear | 09:26:19 |
| ElvishJerricco | that sounds more like a udev thing then, doesn't it? | 09:26:41 |
| Ramses 🇵🇸 | Yeah, that would also work, I guess | 09:27:03 |
| ElvishJerricco | i.e. make udev rules that identify the devices and set the desired property | 09:27:06 |
| ElvishJerricco | though that obviously doesn't work in the example in the PR, which is about transparent_hugepage | 09:27:27 |
| Ramses 🇵🇸 | Yeah, those are exposed by the kernel and always available, I think | 09:44:18 |
 Sandro 🐧 | In reply to @elvishjerricco:matrix.org
Ok, I'm happier with this now: https://github.com/NixOS/nixpkgs/pull/375975 That sounds cool | 09:57:25 |
 Arian | This feels like the kind of thing that should be done with udev rules or device units not tmpfiles | 10:00:22 |
| Arian | Not sure | 10:02:19 |
| ElvishJerricco | the sysfs thing? That only works for sysfs nodes that actually represent devices, which is only a subset of sysfs | 10:14:27 |
| Arian | Ah | 10:18:47 |
| Arian | Then just order it later like https://man7.org/linux/man-pages/man8/systemd-sysctl.service.8.html | 10:19:42 |
| Arian | Surprised there isn't a systemd-sysfs | 10:19:50 |
| Arian | I guess best we can do is load after systemd-modules-load | 10:20:14 |
| ElvishJerricco | hm, currently tmpfiles and modules-load are unordered against each other | 10:23:51 |
 gdamjan | but even if you load a module, the sysfs knobs are not guaranteed to be available immediately right? modules initialize asynchronously | 13:29:29 |
|  derrg joined the room. | 17:33:52 |
