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

[Mauricio Faria de Oliveira <mfo@igalia.com>]

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.

cheers,

> 
> Best

-- 
Mauricio