Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

Constantine A. Murenin cnst at FreeBSD.org
Fri Jul 13 16:14:38 UTC 2007


On 11/07/2007 06:12, Robert Watson wrote:

> On Wed, 11 Jul 2007, Poul-Henning Kamp wrote:
> 
>> In message <469420B9.20401 at FreeBSD.org>, "Constantine A. Murenin" writes:
>>
>>> If you want to have no such framework that could potentially diagnose 
>>> or predict system failure, it's your choice, [...]
>>
>>
>> I would love to have that, but the OpenBSD code isn't that.
> 
> 
> In the general spirit of SoC, I would suggest that a more constructive 
> line of commenting might come with suggestions, not just rejections 
> :-).  Are you arguing that the current proposed framework offers little 
> incremental benefit over simply having the sysctl framework in the first 
> place and having each source of information (i.e., device driver) just 
> export it directly?
> 
> It seems clear that people would like all these measurements to be 
> available, even if not by the precise mechanism proposed.  So far the 
> specific technical criticals have been:
> 
> - There's such a diversity of motherboard devices and probe mechanisms that
>   any kernel driver would become rapidly over-burdened and needlessly
>   complicated.
 >
> This doesn't argue for doing nothing, just that perhaps a kernel device 
> driver is the wrong place.

Most consumer motherboards that are on the market today have either 
Winbond or ITE Tech Super I/O. All of these chips are supported by two 
drivers: lm(4) and it(4). All of these Super I/O attach at isa.

I don't have exact numbers, but in reality, these chips cover almost 
every recent and not so recent motherboard manufactured by Asus, ECS, 
Gigabyte, MSI, AOpen etc.

Documentation for these chips is readily available via anonymous http, 
directly from Winbond and ITE Tech.

(Granted, there are a few problems with resistor recommendations that 
phk mentioned, but this should not stop us from having _simple_ drivers 
for these chips -- they are already written and available in OpenBSD and 
NetBSD, and lm(4) is mostly ported in perforce to FreeBSD, too.)

> - A moderate number of user space tools exist to do this already in the 
> ports
>   collection, and user space is the right place to do this as it doesn't 
> need
>   to be in kernel.
> 
> Part of the argument here has to do with code becoming stale, and one 
> possible outcome of a more actively maintained in-OS framework is that 
> it is better maintained, and that code is shared across platforms.  
> Also, I have to say that I don't run monitoring tools on several of my 
> boxes because I can never figure out which are the right ones to run, 
> and the ones I try inevitably don't work.

That's exactly what this is about -- most people don't run these 
monitoring tools from the ports tree because there are just too many 
options to choose from, whereas in reality few of them have desired 
functionality.

One other important distinction between all of those tools and sysctl 
framework is the lack of a namespace in those tools and artificial 
limitations (e.g. healthd from ports supports exactly 3 temperature 
sensors etc).

Other important factor is that those monitoring tools from ports must be 
run as root, and some of them by default accept non-local connections 
from the network, which poses additional security risks.

All sysctl hw.sensors tools can be run as an unprivileged user. Tools 
are already in place to perform local and remote monitoring, all of 
which can be done as an unprivileged user.

Cheers,
Constantine.


More information about the freebsd-arch mailing list