Re: Detecting changes of misc kernel values

[Elad Efrat <elad%NetBSD.org@localhost>]

Hi,

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 think kqueue/knote will have to go eventually. That said...

> 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...

Please, don't add to the pile of junk we call a "routing socket".

> 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.

Requiring /kern won't fly.

> 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)

Did you think through what EVFILT_SYSCTL means?

> 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:

Ideally, we'll be able to handle a wide range of events, and allow
subsystems to plug in their own events without requiring changes to APIs
and/or ABIs. You know where I'm going with this...

> hostname
> domainname (laptop that roams between NIS domains?)
> securelevel?
> v4 and v6 forwarding-enabled state?

I can't remember about the the last one, but hostname/domainname are
easy to monitor; for securelevel, or any other subsystem-specific value,
you'll either have to do the polling before/after the sysctl handler is
called as it's subsystem private (and then you'll have to have the
subsystem properly "export" the value for you to report to userland) or
add plugs inside the subsystem itself to raise the events (similar to
how file-systems raise knotes).

In other words, I'd isolate your solution to the simple items you need
to avoid---

> I'm interested in:
>  - thoughts pro/con the various options

(the only viable options from your proposal are 4 and 4a)

>  - other options I missed

---writing a much more elaborate, but needed, subsystem to handle all of
this.

>  - other things that should be watchable beyond the five I came up with.

I wouldn't go there. :)

Thanks,

-e.