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"? Best
signature.asc
Description: PGP signature
