| 20 Mar 2025 |
 @elvishjerricco:matrix.org | 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:matrix.org | 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:matrix.org | i.e. make udev rules that identify the devices and set the desired property | 09:27:06 |
| @elvishjerricco:matrix.org | 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:matrix.org | 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 |
