[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: sysctl's in modules - specifically compat_netbsd32
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
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.
Main Index |
Thread Index |