Re: [PATCH RFC v3 00/13] sysctl: add module aliases

On Wed, Sep 09, 2026 at 02:29:30PM -0300, Mauricio Faria de Oliveira wrote:

On 2026-09-09 11:07, Joel Granados wrote:

quoted

On Fri, Sep 04, 2026 at 02:45:23PM -0300, Mauricio Faria de Oliveira wrote:

quoted

On 2026-09-04 10:41, Joel Granados wrote:

quoted

On Thu, Aug 20, 2026 at 06:22:13PM -0300, Mauricio Faria de Oliveira wrote:

quoted

On 2026-08-20 09:51, Joel Granados wrote:

quoted

On Wed, Aug 19, 2026 at 03:16:13PM -0300, Mauricio Faria de Oliveira wrote:

quoted

This series adds 'sysctl:' aliases to modules that register sysctl tables; e.g.:

<... snip ...>

quoted

quoted

use the correct call moving forward?

This scheme currently covers all modules, AFAIK, as it is wrapped in the
functions that register sysctl tables.

On moving forward: usage of such functions in a way that breaks a
requirement of this series (e.g., failing to specify the template
table/path parameter(s), or not having constant initializers) hits a
build error, as the requirements are actually from the compiler.

quoted

quoted

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.

Ok, cool. I can work on a different design.

Please just let me know whether you are OK with the remaining (above),
and I'll be happy to tackle this.

What is "the remaining"?

I meant the rest of the email, addressing the points/questions you
raised.

* The dependency on a sysctl path to load a module still is
  backwards to me. It should be: I need feature A, I load modules
  M{1,2,3} for A and I set sysctl S{1,2,3...}. Not sure why sysctl tools
  do it the other way around.

* The fact that the invariance is in the sysctl path and not the module
  identifier maybe points to a deeper issue. 

* I still believe that this is better placed outside the sysctl
  subsys as it does not cater solely to module loading.

Best