From owner-cvs-all@FreeBSD.ORG Mon Oct 15 18:39:16 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FEB216A41A; Mon, 15 Oct 2007 18:39:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id E9F1213C45B; Mon, 15 Oct 2007 18:39:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 214537876-1834499 for multiple; Mon, 15 Oct 2007 14:36:31 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l9FIc83n075302; Mon, 15 Oct 2007 14:38:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Alexander Leidinger Date: Mon, 15 Oct 2007 14:34:40 -0400 User-Agent: KMail/1.9.6 References: <24712.1192384461@critter.freebsd.dk> <47131B2F.1060900@samsco.org> <20071015154321.tl6x9nb9lwwgk8o8@webmail.leidinger.net> In-Reply-To: <20071015154321.tl6x9nb9lwwgk8o8@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710151434.41801.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 15 Oct 2007 14:38:09 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4540/Sat Oct 13 21:43:55 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Scott Long , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, Poul-Henning Kamp , Wilko Bulte Subject: Re: cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf files ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 18:39:16 -0000 On Monday 15 October 2007 09:43:21 am Alexander Leidinger wrote: > Quoting Scott Long (from Mon, 15 Oct 2007 01:47:59 -0600): > > > Alexander Leidinger wrote: > >> Quoting Poul-Henning Kamp (from Sun, 14 Oct > >> 2007 17:54:21 +0000): > > >>> listen to the various mumblings about putting RAID-controller status > >>> under sensors framework. > >> > >> What's wrong with this? Currently each RAID driver has to come up > >> with his own way of displaying the RAID status. It's like saying > >> that each network driver has to implement/display the stuff you can > >> see with ifconfig in its own way, instead of using the proper > >> network driver interface for this. > >> > > > > For the love of God, please don't use RAID as an example to support your > > argument for the sensord framework. Representing RAID state is several > > orders of magnitude more involved than representing network state. > > There are also landmines in the OpenBSD bits of RAID support that are > > best left out of FreeBSD, unless you like alienating vendors and risking > > legal action. Leave it alone. Please. I don't care what you do with > > lmsensors or cpu power settings or whatever. Leave RAID out of it. > > Talking about RAID status is not talking about alienating vendors. I > don't talk about alienating vendors and I don't intent to do. You may > not be able to display a full blown RAID status with the sensors > framework, but it allows for a generic "wors/works not" or > "OK/degraded" status display in drivers we have the source for. This > is enough for status monitoring (e.g., nagios). As I mentioned in the thread on arch@ where people brought up objections that were apparently completely ignored, this is far from useful for RAID monitoring. For example, if my RAID is down, which disk do I need to replace? Again, all this was covered earlier and (apparently) ignored. Also, what strikes me as odd is that I didn't see this patch posted again for review this time around before it was committed. -- John Baldwin