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