Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD



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@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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"