Re: sysctl's in modules - specifically compat_netbsd32

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Sat Dec 13 2008 at 17:00:20 -0800, Paul Goyette wrote:
> While tracking down some strange-looking entries in dmesg (as mentioned 
> on current-users) it occurs to me that the current sysctl architecture 
> doesn't lend itself well to having loadable modules declaring new sysctl 
> entries with CTLFLAG_PERMANENT set.  Of particular interest is module 
> compat_netbsd32 which has its own netbsd32_sysctl_init() routine.
> 
> This routine is called long after the main sysctl_init() has finished 
> and marked the tree as having been set-up (set CTLFLAG_PERMANENT on the 
> root node).  Yet this routine attempts to create several PERMANENT 
> nodes.  These attempts all fail, generating the strange-looking dmesg, 
> but the nodes they attempt to create are apparently created elsewhere, 
> so there's no real damage.
> 
> For the specific case, it would seem that netbsd32_sysctl_init() is 
> superfluous and unnecessary.  But there might be other modules that want 
> to create entries, and those will fail if the entries being created are 
> marked PERMANENT.  Since modules can be unloaded, it seems to me that 
> modules' sysctl()s should not be marked PERMANENT.

This is a problem with sysctl.  Basically there should be a way to say
"this is a system-provided node, but it can be unloaded if the code
providing it is unloaded".  Now you can work around the problem simply
by providing a storage parameter for the unwind log (which internally
removes the permanent flag).

Hmm, looking at the code netbsd32_sysctl_init() already provides
the log parameter.  It must be tripping on something else besides
CTLFLAG_PERMANENT.

Incidentally, sysctl node registrations in general should move away from
link sets to provide for modules.  I did a little bit of it recently,
but there's still a lot left.