Sysctl as a Service, or: making sysctl(3) more friendly for monitoring systems

[Warner Losh]

On Mon, Dec 12, 2016 at 10:29 PM, Warner Losh <wlosh at bsdimp.com> wrote:
>
>> On Dec 12, 2016, at 10:27 PM, Peter Jeremy <peter at rulingia.com> wrote:
>>
>> On 2016-Dec-12 17:57:07 -0700, Warner Losh <imp at bsdimp.com> wrote:
>>> On Mon, Dec 12, 2016 at 6:34 AM, Ed Schouten <ed at nuxi.nl> wrote:
>>>> $ time ./prometheus_sysctl_exporter | wc -l
>>>>        0.00 real         0.00 user         0.00 sys
>>>>    3162
>>>>
>>>> If our sysctl tree would get substantially larger at some point, we
>>>> should of course revisit this.
>>>
>>> That sounds cool. I'd love to see what you came up with to get those results.
>>
>> I think that's impressive as well.
>>
>>> While we're here... there's one thing I'd love to see from  a
>>> hypothetical /dev/sysctl... When a sysctl value changes (or some
>>> subset), I'd like it to appear on a read-channel. That way, I could
>>> monitor temperature w/o needing to constantly poll for changes, for
>>> example.
>>
>> That sounds like a job for kqueue(2), though it would need to be plumbed
>> through.  The biggest problem I see is that nothing in the sysctl mechanism
>> has any way of reporting that a value has changed and so consumers of that
>> data should re-check.  This means that you'd probably just wind up polling
>> in the kernel.
>
> It does if you had a read-channel :)

Yea, forgot about the pointer case, you're right. This is a cool idea,
but it can't work.

Warner