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.
* 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
signature.asc
Description: PGP signature
