On 2026-09-10 04:29, Joel Granados wrote:
> On Wed, Sep 09, 2026 at 02:29:30PM -0300, Mauricio Faria de Oliveira wrote:
>> On 2026-09-09 11:07, Joel Granados wrote:
>> > On Fri, Sep 04, 2026 at 02:45:23PM -0300, Mauricio Faria de Oliveira wrote:
>> >> On 2026-09-04 10:41, Joel Granados wrote:
>> >> > 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.:
>> > <... snip ...>
>> >> > 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.
>> >>
>> >> >> 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.
Right, but note:
- the feature may, or may not, be built as a module (unknown to sysctl
tool).
- there is no simple way to identify which module provides a sysctl,
today.
Let's compare this with device-id module aliases: userspace doesn't know
whether a driver is built-in or a module, but it can load the module, if
any, based on the device-id, not the module name.
> * The fact that the invariance is in the sysctl path and not the module
> identifier maybe points to a deeper issue.
It does seem that the invariance in the sysctl path is correct, as that
doesn't change with the variable of whether the code is built-in or a
module.
A similar comparison with device-id module aliases applies, IIUIC.
> * I still believe that this is better placed outside the sysctl
> subsys as it does not cater solely to module loading.
Understood; your point about a module-specific argument in sysctl
register functions precisely confirmed that this approach is misplaced.
I'll try a different design, more similar to MODULE_DEVICE_TABLE().
Maybe the only requirement from sysctl is for struct
ctl_table.procname's offset to be zero (for file2alias). And apparently
something with the path string in a table declaration macro. We'll see.
Thanks again for reviewing and providing constructive feedback. That's
very appreciated.
>
> Best
--
Mauricio
