Porting OpenBSD's sysctl hw.sensors framework to FreeBSD (was: Re: PERFORCE change 123040 for review)

Robert Watson rwatson at FreeBSD.org
Sun Jul 8 11:09:05 UTC 2007


On Sat, 7 Jul 2007, 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?

While Andre's proposed goal of eliminating static sysctl nodes for 8.0 is 
laudable, a casual glimpse run found 261 references to top-level CTL_ 
constants in src outside of the kernel, so there's quite a bit of work to be 
done, as well as some rather serious ABI issues to address if we want that to 
happen.  As such, while we can fix the consumers, I think simply eliminating 
support for static OIDs in 8.0 is likely unrealistic.

In general, it is desirable, however, for all new nodes to be created using 
OID_AUTO rather than hand-humbering in order to avoid introducing any further 
ABI dependencies on static OID allocation.  All recent large node hierarchies 
have used automatic OID numbering, including the top-level compat, sysctl, and 
security hierarchies.  I would like to see the hw.sensor subtree also use 
automatic OID numbering for the same reason.

While the sysctlbyname(3) API has its limitations, it is straight forward to 
use, and automatic OID numbering has both code cleanliness and compatibility 
benefits -- for example, when companies or organizations have heavily modified 
local FreeBSD installs, it prevents otherwise unresolvable collisions that 
would lead to ABI incompatibility.

Robert N M Watson
Computer Laboratory
University of Cambridge


More information about the freebsd-arch mailing list