This WE I was told that FreeNAS seems to want to move from FreeBSD to Linux (since then it seems there could be a linux and a FreeBSD version). One of the reasons seems to be a missing sensors framework.

As I was committing a port of the OpenBSD sensors framework (produced as part of the Google Summer of Code 2007) to FreeBSD and had to remove it afterwards because one committer complained very loudly, I was asked what the status of this is.

The short status is: Nobody is doing something about it.

Before I explain the long status, I give  a short overview what this sensors framework is:

• a kernel API which allows to add sensors
• an interface for the userland to query the sensor data
• some basic userland code to show and log the sensor info

The API and the query interface are more or less independent. For the userland code it was more a logging infrastructure than a real monitoring solution. The reason was the real monitoring solutions already exist (Nagios, snmpd, …) and can be adapted to query the sensors. Ideally a query in userland should be handled by a library instead of directly accessing the sysctl interface, this way the kernel<->userland interface would be abstracted away (and could b replaced as needs arise). This was not done, it was something to be done later (Rome was not build in a day).

The userland interface also only cared about dumb sensors (those which you need to query manually to get the information), smart sensors (those which are able to send events themself) where not taken care about in the sense of really sending sensor-triggered events, but the kernel API allowed to add such sensors. The sysctl interface has no way of sending events, but FreeBSD already has an event interface (devd is taking care about it). It would have been not a problem to send events via this channel and let an userland library take care about the delivery together with other sensor-data in userland.

And now the long status is:

PHK complained loudly about it. First he said he did not look at it but he complained that is not good regardless. After a lot of nagging from me he had a look at it and was not happy about the time stuff in it (short: the FreeBSD timecounter code is better). This was not a problem in my opinion, we could have disabled this part without problems. After such an offer from me, he complained that the sensors framework uses the sysctl interface instead of an entry in /dev.

At this point in time already several userland utilities used the sysctl framework to query for status data in the kernel. So there was already precedence for such an use of it. Later some more such uses where added too (e.g. the procstat stuff by core team member Robert Watson).

I saved some of the corresponding mails (to public mailing lists) in a mbox file, read the mess yourself if you want.

The bottom line is: Several committers (even some which we could call high profile committers) told me that they do not see a problem in the use of the sysctl interface. They do not seem to want to tell it in public (nobody of them voiced their opinion in the thread, so do not ask me who those people are). I am not interested in investing more of my spare time into fighting windmills (it looks like this to me).

So, if someone is intersted in the code, r172631 has it. In the perforce repository you can maybe find some sensors. I think most of it can still be used without much changes.

If someone tries it with a more recent FreeBSD, please drop me a note if it just applies fine, or a patch (or an URL to it) if it needs some modifications. Who knows, maybe in a future project it may be useful for me.

If there is enough interest by several people, I can even put up a wiki page where those people can coordinate, but that is most probably all I am willing to invest further into this (at least in my unpaid time).