Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

[Sam Leffler]

Constantine A. Murenin wrote:
> On 07/07/2007 04:40, Andre Oppermann wrote:
> 
>> Rui Paulo wrote:
>>
>>> Constantine A. Murenin wrote:
>>>
>>>> http://perforce.freebsd.org/chv.cgi?CH=123040
>>>>
>>>> Change 123040 by cnst at dale on 2007/07/06 23:45:36
>>>>
>>>>     add new node to sysctl.h:         HW_SENSORS / "hw.sensors"
>>>
>>>
>>> Hmm. I thought new sysctl nodes or leafs were dynamic and you needn't to
>>> add any entry to sysctl.h.
>>
>>
>> Yes, all new sysctl nodes and leaves should be entirely dynamic.
>> The (old) static ones should go away with 8.0 or so.  IIRC there
>> hasn't been any new static sysctl node since a loooong time.
> 
> I don't exactly consider April 2007 being a loooong time ago. ;)
> 
> So even first- and second-level nodes must be generated dynamically by 8.0?
> 
> Hardware sensors tree is going to be pretty deep down. Under sysctl(8)
> the variable names will look like this:
> 
>     hw.sensors.lm0.temp0
> 
> whereas in reality, the tree has five levels:
> 
>     hw.sensors.lm0.temp.0
> 
> but as an exception to sysctl rule -- specifically for hw.sensors -- in
> OpenBSD the last dot is ommitted from sysctl(8) presentation to the
> user, to improve readability and preserve some sanity. :) I want to keep
> FreeBSD's sysctl hw.sensors tree compatible with the one in OpenBSD, so
> that both sysctl(8) shell scripts and sysctl(3) C utilities will be
> portable between the systems.
> 
> Any suggestions are welcome, and let me know if you have any questions
> about the framework itself -- I'm the principal author of the current
> "two-level" revision of the framework on OpenBSD, so I know everything
> that is immediately relevant on how it works. ;)
> 
> P.S. Obviously, what I say here about sysctl(8) variable names will
> equally apply to FreeBSD's sysctlbyname(3).
> 
> P.P.S. Here is a sample output of a recent sysctl(8) on OpenBSD
> 4.1-current, on a consumer-grade G965-based Core 2 Duo system, with a
> pretty standard Winbond W83627DHG Super I/O:
> 
> dale: {3360} dmesg | fgrep -e "cpu0: Intel" -e lm | tail -n2
> cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class)
> 1.81 GHz
> lm0 at isa0 port 0x290/8: W83627DHG
> dale: {3361} sysctl hw.sensors.{cpu0,lm0.{temp,fan,volt{0,1,2,7}}}
> hw.sensors.cpu0.temp0=28.00 degC
> hw.sensors.lm0.temp0=58.00 degC
> hw.sensors.lm0.temp1=24.00 degC
> hw.sensors.lm0.fan1=917 RPM
> hw.sensors.lm0.volt0=1.15 VDC (VCore)
> hw.sensors.lm0.volt1=12.30 VDC (+12V)
> hw.sensors.lm0.volt2=3.33 VDC (+3.3V)
> hw.sensors.lm0.volt7=3.31 VDC (3.3VSB)
> dale: {3362}
> 
> And let me warn you that the framework supports many more things than
> just temperature sensors -- from raid drive status to NMEA time offsets! :)

Compatibility is a worthy goal and in this case fixing the 2nd level mib
may be fine.  But please recognize that openbsd != freebsd and some
design decisions may turn out differently on freebsd.  The p4 depot is
provided specifically so you can explore different designs w/o polluting
CVS.  But before any code like this goes into CVS it will need review
and at that point you may find decisions such as this questioned.

	Sam