On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote: > On 2026-08-20 09:51, Joel Granados wrote: > > On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote: > >> This series adds 'sysctl:' aliases to modules that register sysctl tables; > >> e.g.: > >> > >> $ modinfo ./mpls_router.ko | grep sysctl: > >> alias: sysctl:*/net/mpls/conf/*/input > >> alias: sysctl:*/net/mpls/default_ttl > >> alias: sysctl:*/net/mpls/ip_ttl_propagate > >> alias: sysctl:*/net/mpls/platform_labels > >> > >> It provides a trivial way to map /proc/sys files to modules (not trivial > >> today), > >> and for userspace to handle nonexistent /proc/sys files (e.g., procps's > >> sysctl > >> and systemd-sysctl applying tunables) with "modprobe sysctl:<...>" and a > >> retry. > >> > >> This is done almost automatically with register_sysctl(), > >> register_net_sysctl() > >> and friends as wrappers of MODULE_SYSCTL_TABLE (similar to > >> MODULE_DEVICE_TABLE), > >> which emits symbols for file2alias/modpost to find and parse the sysctl > >> tables. > >> > >> The big exception to 'almost' are sysctl tables and paths allocated or > >> defined > >> at runtime (e.g., per-namespace or per-device), as all information is > >> required > >> at build-time. Fortunately, such tables and paths are often based on > >> 'templates' > >> which are static and can be used. > >> > >> This is done by plumbing the template table/path as optional arguments > >> (macros > >> with default values as default_gfp()), so not to create functions for all > >> cases: > >> > >> register_sysctl(path, table [, table_tmpl [, path_tmpl]]); > >> register_net_sysctl(net, path, table [, table_tmpl[, path_tmpl]]); > >> register_net_sysctl_sz(net, path, table, size [, table_tmpl[, > >> path_tmpl]]); > > > > The "what" is described but I'm missing more clarity on the "why". Why > > does this need to be trivial? Where is it that you will know the sysctl > > file path of a module and not the module name or alias? > > Thanks for looking at this. > > The problem this feature addresses is sysctl settings not applied > because modules aren't yet loaded when systemd-sysctl/procps's sysctl > runs on boot, and the usage of /etc/modules as a workaround.
Sorry for insisting, but is it not possible to set the sysctls after the modules have been loaded? Why is the order to first set the sysctl and then load the module? > > This can be addressed with a way for sysctl tools to load the module for > a non-existent sysctl file path. > For that, the mapping between a sysctl file path (known) and its module > (unknown) needs to be trivial. This touches on my question. How is the file path known and the module not known? The module is the one providing the paths, not the other way around. Why choose to just work with sysctl path lists and not include the modules that go with them? > > It may not seem serious at first, but I've seen this consume significant > engineering time and impact production systems, in a previous technical > support job. > An example: cloud deployments with non-scalable network routing > performance due to nf_conntrack_max not applied after reboot or an > upgrade because the component which turned out to help with the > /etc/modules workaround had its placement changed from network router > nodes. This is more understandable to me. The issue is that you loose the relationship between sysctl paths and modules on updates. Are there other cases where the module would not be loaded? And doesn't it create another problem where you will load modules that you don't expect (on the update)? > > > Additionally, sysctls are not module specific; they are a way to > > read/write kernel variables. Putting a module specific aspect in the > > function arguments (that needs to be ignored in non-module cases) seems > > wrong. Why not use the module subsys to add sysctl alias instead of the > > sysctl subsys? > > Fair point. The current design has 2 reasons: > > 1) Use the 'path' argument (raised in [1]), only available in the > register sysctl functions. > 2) Use a more implicit/transparent approach, instead of more > explicit/declarative approach. I get that the data is there and you would be able to do it, but it still seems misplaced. Additionally, are you planning to move all the modules to this scheme? If not, does that mean that some modules would work and some wouldn't? And how would you make sure that modules would use the correct call moving forward? > > I guess that a different design could use MODULE_SYSCTL_TABLE() as > MODULE_DEVICE_TABLE(), declared per table instead of wrapped into > register sysctl functions. > However, it seems to require moving the value of the path argument (or > its template) into the macro and still referencing it in the function > (or its instantiation of the template), which adds obfuscation, to all > callers. > > What do you think? It might be that having it inside the module subsys is more work, but I believe that there is the right place to have it. I still don't see that adding a module specific arg to the sysctl register is a good thing. Best
signature.asc
Description: PGP signature
