[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Detecting changes of misc kernel values
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
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...
domainname (laptop that roams between NIS domains?)
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
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
- other things that should be watchable beyond the five I came up with.
I wouldn't go there. :)
Main Index |
Thread Index |