Date: Fri, 13 Jul 2007 12:14:27 -0400 From: "Constantine A. Murenin" <cnst@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Rui Paulo <rpaulo@fnop.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "Constantine A. Murenin" <cnst@FreeBSD.org>, Shteryana Shopova <syrinx@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <4697A4E3.5070901@FreeBSD.org> In-Reply-To: <20070711104247.P58526@fledge.watson.org> References: <55754.1184143579@critter.freebsd.dk> <20070711104247.P58526@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/07/2007 06:12, Robert Watson wrote: > On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: > >> In message <469420B9.20401@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4697A4E3.5070901>