As people are starting to ask questions, and other people are asking for an undeadly article, here you go. :)

New two-level sensor API

OpenBSD 4.0-current has a two-level sensor API starting from 2006-12-23. Theo de Raadt committed my patch that converts sys/sensors.h header file, kern_sensors.c framework implementation, all device drivers, sysctl(3), sysctl(8), as well as sensorsd(8) and ntpd(8), along with all manual pages, to the new API, a prototype of which was originally developed for my final year computing project at De Montfort University, supervised by Dr. Jordan Dimitrov and Prof. Mikhail Goman.

two-level API from the kernel-space view-point

How it was before

Previously, each driver was adding sensors to a common pile of sensors, which were then accessible via sysctl(3). Although sensors already had a concept of sensor type, sensors were still numbered in a global fashion, where no two sensors on the system could have had the same number.

I.e. if lm0 already had a sensor with number ‘0’ that showed fan speed, then it could not simultaneously have had a sensor with number ‘0’ showing temperature. Moreover, once lm0 would register, say, 15 sensors, which would automatically get numbers from 0 to 14 if lm0 was the first device trying to register sensors, then lm1 sensors would have to live with being numbered 15 and above (and, say, ses0 — 30 and above). I.e. with the way it was, to monitor the first temperature sensor on lm0, you had to call for hw.sensors.10; whereas the first temperature sensor on lm1 would have been hw.sensors.25.

Moreover, as sensor numbering could not have been trusted for anything remotely useful (apart from the count of how many total sensors you might have), it led to the abuse of the sensor description attribute within the drivers using the framework, where a lot of drivers had "Temp1", "Temp2", "Temp3" etc null-terminated strings hardcoded into them, or had a loop creating these null-terminated strings on the fly, which still was an unoptimal solution.

How it is now

Now sensors API has a concept of sensor device, where each driver that supports sensors adds them via sensor_attach(9) to its own sensor device structure (struct sensordev), and then registers its sensor device with sensordev_install(9) within the sysctl(3) framework.

This immediately adds the benefit of having a separate sensor count for each driver instance, i.e. lm0 and lm1 could both have sensors numbered ‘0’! However, we didn't want to stop there, and used an automatically-updated array maxnumt counting the maximum number of sensors of each type a sensor device has — after having this information, we could reset sensor numbering with each type on each sensor device! (Without having such information, you'd have to loop around sysctl a lot in trying to find all possible sensors of all possible types. This array limits such unnecessary looping.)

Not only does this make things simpler from the conceptual understanding of which sensor comes from which device, as well as unifies the information about how many sensors of each type each sensor device has, but because of these improvements, we were able to free most drivers of any types and ordinal numbers in sensor description fields. I.e. "Temp1", "Fan1" and the like were all removed from lm(4), it(4), fintek(4) etc driver definitions, shrinking the kernel by a noticeable amount!

So this two-level sensor API not only improves functionality and rationality, but it also shrinks the kernel without any reduction in functionality!

three-level sensor addressing from the userland prospective

sysctl(8) and sensorsd(8) now use a different naming scheme for specifying sensors. A picture is worth a thousand words, so here is some demonstration of what this framework means to you:

$ sysctl hw.sensors.lm0.{temp{0,1},fan,volt{1,2}}
hw.sensors.lm0.temp0=52.00 degC
hw.sensors.lm0.temp1=44.00 degC
hw.sensors.lm0.fan1=2789 RPM
hw.sensors.lm0.volt1=11.55 V DC (+12V)
hw.sensors.lm0.volt2=3.33 V DC (+3.3V)

Notice that this three-level addressing will provide tremendous simplification for many shell scripts, and will undoubtedly improve their portability!

Future plans?

You can expect more sensorsd(8) improvements soon, as well as some new features and improvements for lm(4)/it(4)/abstm(4)/fcu(4)/fintek(4), so stay tuned for some more mojo. :)

Moreover, feel free to mail me (mureninc@gmail.com) your dmesg, `sysctl hw`, `fgrep sensorsd /var/log/daemon` and /etc/sensorsd.conf as you deem appropriate, before and after the change, inline text/plain format, please. More data about how people use the framework will help me optimise future development.

Credits?

Dr. Jordan Dimitrov and Prof. Mikhail Goman for supervising my final year project where a prototype of this framework was originally developed; Alexander Yurchenko for initial explanation of the rationale behind the previous framework; David Gwynne for providing some useful feedback on the prototypes; Theo de Raadt for his continued passion towards development of secure and simple operating systems and for his very valuable advices on how operating systems should be developed; and also Marco Peereboom, Leszek Zarzycki, Ray Miller (UKUUG) and Tom Cosgrove.

Happy holidays!

subj. :)