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).
Thanks for your work, I hope your code to be merged back to FreeBSD.
Not having sensors support it is a major luck of functionality and I surely understand the reasons of the migration of freenas to linux.
I am an sysadmin and I want to know all the time what happens to the inner of the servers case’s.
For this reason I have migrated several servers from FreeBSD to Linux because knowing the operation states of several hardware pieces it is crucial and mandatory for sysadmins for the server availability and overall security architecture.
“PHK complained loudly” : perhaps freebsd team should exclude this people : We are all waiting for “sensors” for a real long time. PHK cost us much more than just than “hey look at freebsd, they even lost freenas”. I’m using FreeBSD for more than a decade, not only I discovered today that the major thing missing for monitoring my customers had been voided by a sort of elitist commiter, but also that the community had lost one of the too main projects..
They’re is only one way to go forward, put back your code into the tree. In real life, nothing is “freezed”, even if your code was really “bad”, anybody can rewrite the bad parts; that’s the way opensource works.…
(Sorry for my poor english)
Sensor support is a “small” problem for me: What I don’t understand is why the FreeBSD team refuse to include the geom_raid5 module used in FreeNAS !
The existing geom_vinum module included in FreeBSD 6⁄7 is too buggy for RAID 5: This is why FreeNAS uses another not-official more stable geom module. But this module was never accepted to be included in FreeBSD. Now the original developer of geom_raid5 stop to maintains it (discouraged), and it’s very hard to found someone to adapt it to FreeBSD 8.0.
AFAIK geom_vinum was updated for FreeBSD‑8. I can not remember to have seen a post about geom_raid5 on current@ or hackers@. Do you have a pointer to a discussion regarding this on a public FreeBSD-mailinglist? If this was not discussed on a FreeBSD mailinglist, I suggest to start a discussion there.
1. FreeNAS is not “moving to Linux” – yes there’s a new project coreNAS that will. But I hope anyone who decides to change underlying platforms to use Linux is doing so for more reasons than just the sensor framework. Anyway coreNAS will be one of dozens of Linux NAS projects. We use FreeNAS specifically to leverage FreeBSD storage technologies (gjournal, iscsi, zfs) and have learned enough through customization that we will just stick with FreeBSD if FreeNAS ever goes away (and right now it is not).
2. PHK is not just “some elitist committer”, sheesh. If PHK has concerns about impact on the kernel we should stop and listen – his vote gives him the ability to make people stop and listen. He might be a bit Danish in his directness but not everyone can be the diplomat a la RWatson. PHK was given his vote for a reason so there’s no reason for acrimony. Whats more he is not the only person who has problems with the OpenBSD sensor framework. It’s not 100% loved amongst OpenBSD devs and users (using it for RAID is going to be a problem).
3. It’s great that constantine and alex did this work. If it is truly “non-disruptive” and can be separated from the kernel then why not just maintain it as a port/patch. Lots of ports of things that never make it into the kernel live on and do all kinds of stuff like building custom kernel modules and user space tools for managing themselves. If the sensors framework can’t do that then perhaps it is too disruptive to include by default.
I bet if you maintain a patch on CURRENT targetting 9.0 and lots of people will try it.
4. it might not seem like it but it’s still early days … 🙂
The discussion began the 06 Nov 2007 on the FreeBSD current mailing-list:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007 – 11/msg00342.html
It looks like the discussion stops in the middle of resolving some issues. BTW: the developer interested in getting this in the tree (Ulf) is also the geam_vinum developer.
As it looks to me after reading the thread, that some important work needs to be done before it can go in.
Maybe you want to contact lulf@ to know if there where some parts handled off-list and what the status of it is.
Just wanted to drop a line that couple of month ago I adapted sensors code to head version of FreeBSD and I’ve been using it since then. I am using only it(4) driver though, and not doing anything fancy.
As such I made couple of small improvements to it(4), including support for 16-bit fan speed counters.
Here’s my current diff against head:
http://people.freebsd.org/~avg/sensors9.diff
This is infuriating, especially now that the coretemp module reports it’s temperatures in sysctl
Has anyone taken it upon themselves to get this merged into 8.2?