Date: Wed, 11 Jul 2007 11:12:24 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Rui Paulo <rpaulo@fnop.net>, Shteryana Shopova <syrinx@FreeBSD.org>, freebsd-arch@FreeBSD.org, "Constantine A. Murenin" <cnst@FreeBSD.org> Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <20070711104247.P58526@fledge.watson.org> In-Reply-To: <55754.1184143579@critter.freebsd.dk> References: <55754.1184143579@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. - 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. - This service is redundant with respect to existing IPMI interfaces, and that perhaps the IPMI interfaces are preferred as they interact better with simultaneous ROM flashing, etc. Undoubtably true. However, the proposed sensor framework isn't just about motherboard monitoring, but also about monitoring a range of devices, and if you've never struggled to get IPMI to just work on a box then you haven't used IPMI :-). It seems you have a more structural argument, but I think the nature of that argument will become more clear if you say what it is you'd like to see in terms of an alternative approach. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070711104247.P58526>