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
