Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Jul 2007 19:36:11 -0700
From:      Sam Leffler <sam@errno.com>
To:        "Constantine A. Murenin" <cnst@freebsd.org>
Cc:        Rui Paulo <rpaulo@fnop.net>, Shteryana Shopova <syrinx@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org>, Andre Oppermann <andre@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD
Message-ID:  <46904D9B.7030807@errno.com>
In-Reply-To: <46904153.7040909@FreeBSD.org>
References:  <200707062345.l66Njpx3091970@repoman.freebsd.org>	<468ED66E.5080400@fnop.net> <468F517D.3010709@freebsd.org> <46904153.7040909@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46904D9B.7030807>