Re: Detecting changes of misc kernel values

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Tue, 20 Oct 2009 11:15:57 +0200, Christoph Egger
<Christoph_Egger%gmx.de@localhost>
wrote:
> On Tuesday 20 October 2009 01:27:03 Ty Sarna wrote:
>> 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'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.

Seconded; however, the migration is already signaled back to userland
through powerd(8), so some machdep changes can already be noticed by
userland, if required. Anyway, migrating VMs across different CPU vendors
or different instruction sets will fail badly. Some in kernel structures
are patched during boot also, so this problem is more general that just
tracing changes of in kernel values.

I am all for a way of monitoring changes of some sysctl values though, even
if it requires to rewrite some of them (those being just a reference to in
kernel variables come to mind, machdep.sse2 being one of them).

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost