Re: Detecting changes of misc kernel values

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Tuesday 20 October 2009 01:27:03 Ty Sarna wrote:
> I have a need to detect when the hostname changes. There is presently
> no way to do this, short of polling, or requiring an admin to manually
> kick interested processes with -HUP or something. As systems become
> more mobile and dynamic, it'd be nice to be able to write code that
> Just Works when various system state changes, user interfaces that
> reflect current state accurately and automatically without imposing
> lots of overhead for polling, etc. Most of the biggies are already
> covered either by various kqueue filter types (though we don't
> implement all of them yet, like EVFILT_FS), the routing socket,
> envsys, etc. What's left are a few odds and ends that don't quite fit
> anywhere else.
>
> I can think of a few ways to address this:
>
> 1) A new message type on the routing socket. While one could argue
> that a changing hostname is network-related change, this stretches the
> concept of the routing socket a bit too much for my taste...
>
> 2) kqueue, using EVFILT_VNODE on /kern/hostname. I consider this a non-
> starter because there has been longstanding resistance to make base
> utilities depend on any particular filesystem being mounted (eg, ps
> does not depend on procfs). Also, making this work right, with kernfs
> triggering an event when the hostname changes by non-kernfs means
> (which is the common case), is kind of tricky. I'm afraid it might
> require too much intimacy between kernfs and the rest of the kernel.
>
> 3) kqueue, with a new EVFILT_SYSCTL, as a way to watch arbitrary
> nodes. There are issues with this: Although kevent.ident is a
> uintptr_t, nothing currently supports it being a pointer, which it
> would have to be to reference a sysctl node (variable-length, won't
> fit directly). Also, supporting arbitrary nodes is difficult or
> impossible, since sysctl in the kernel can simply be pointed at a
> given variable and has no way of knowing when the value changes behind
> its back. I'm not keen on having it be hit-or-miss on which nodes are
> supported, or having lots of code to support all sorts of nodes on a
> case-by-case basis when most of them are of no interest, or can
> already be watched in other ways (eg kern.proc vs EVFILT_PROC)
>
> 4) kqueue, with a EVFILT_KERN (or _MISC, or what have you), supporting
> monitoring a fixed small (<= 32) set of "kernel global variable" kinda
> things, using a bit per item in kevent.fflags.
>
> 4a) like 4, but with an enumeration of values to be put in "ident"
> rather than using bits in fflags, if it seems likely more than 32
> would be needed.
>
> I lean towards 4 or 4a as it's simple, doesn't add much code (he says,
> not having tried to implement it yet), and I couldn't think of too
> many things one would want to monitor for changes anyway.  The list I
> came up with (and some of these may be a stretch) is:
>
> hostname
> domainname (laptop that roams between NIS domains?)
> securelevel?
> v4 and v6 forwarding-enabled state?
>
>
> I'm interested in:
>   - thoughts pro/con the various options
>   - other options I missed
>   - other things that should be watchable beyond the five I came up
> with.

5) notification for sysctl and dynamic linker
On x86 we have machdep.sse and machdep.sse2. We can tell the dynamic linker in
ld.so.conf to load optimized sse libs.
On migration the underlying hw can change. This can not just happen with jym@
work on the xen-port, NetBSD as an HVM guest can also get migrated.
If NetBSD is migrated to a host which doesn't have sse/sse2, then the
machdep.sse / machdep.sse2 sysctl need to be cleared and the dynamic linker
has to be notified to unload the optimized libs and libc should automatically 
fall back to the default.

Christoph