From owner-cvs-all@FreeBSD.ORG Tue Oct 16 03:32:26 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 885DA16A41B for ; Tue, 16 Oct 2007 03:32:26 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.freebsd.org (Postfix) with ESMTP id 26A1813C468 for ; Tue, 16 Oct 2007 03:32:25 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so901960wra for ; Mon, 15 Oct 2007 20:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=8h/DkOROPFVA2NO6EiAyhiWDFlEwtgoOWbC7V/FIR5E=; b=npCfUv70oMZ27dVxk2ej1LFvK1RJNncU6yXeeyqwSmxgoeTvTa9Z7EDSt592OwCEdrOb4xe0TSNTw7gW3GZfGh00rSJnyGAE0ma/Azl/Zk3nfNed0XQXWI2tDvnPL9c0gcjMWh7tl/M6ULn+pQgruFP4csoPBgQXOlpu24QC1Qs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=ctcpHDx46Pu/ZsuMfommjb/5NHF5og27Zlimkye4KXHvLYHeEzzUjtYjU7AxBzkrxkV35QTjWsxGNWbwNFmfukv2/2+KNDm6NK/2blHLkAvlzpPcTVVhUxKWnOJijXv/OGHIkLqkCONPi8GTO7G+YAl9VMKwgQiJ5TfRsEcySDs= Received: by 10.90.34.9 with SMTP id h9mr9854139agh.1192505545213; Mon, 15 Oct 2007 20:32:25 -0700 (PDT) Received: by 10.90.78.10 with HTTP; Mon, 15 Oct 2007 20:32:25 -0700 (PDT) Message-ID: Date: Mon, 15 Oct 2007 23:32:25 -0400 From: "Constantine A. Murenin" To: "Alexander Leidinger" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Scott Long , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, "Constantine A. Murenin" , 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 f 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: Tue, 16 Oct 2007 03:32:26 -0000 On 15/10/2007, 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). I don't know if you > talk about the OpenBSD bio framework or about some reverse engineered > RAID drivers in OpenBSD (or bad mails from them to some vendors). From > an user point of view the bio framework (as in "a generic interface > for the sysadmin to do RAID stuff", and not as in "the concrete > implementation in OpenBSD") is something you want to have. I don't > think that it is a bad idea to port it (and improve it). OpenBSD has > some RAID controllers converted to it and the framework already > represents an usable interface for a lot of cases. I don't know if it > needs improvement or not, I don't know if it can cover all current > feature needs for such a framework for all possible RAID systems (most > probably not), but it would be an improvement for vendors which want > to write support for their RAID hardware as they don't have to come up > with their own BSD code to manage those parts. And we could improve > "our bio framwork" (if we had/get one) based upon vendor feedback (we > already improved our network interfaces upon vendor feedback, haven't > we?). In case you talk about porting some "alienated" raid drivers > from OpenBSD... I agree that it is not a good idea to kick a vendor in > the ass (a vendor which provides some kind of FreeBSD support... if > there's a driver for raid hardware for which the vendor doesn't > provide any support for a driver for FreeBSD at all, it depends upon > the specific driver code from OpenBSD if it is a good idea to port it > or not). > > So in short: having a generic framework would be beneficial for > vendors. Kicking vendors in the ass is not my intention. Feel free to > document pitfalls in the RAID stuff in OpenBSD, so that nobody in > FreeBSd-land makes the same mistakes (but is able to get good parts if > the idea of an unified interface into FreeBSD). > > Sorry for not taking the time to write a more readable mail. > > Bye, > Alexander. BTW, the RAID status part of the sensors framework was already ported into NetBSD's sister framework, envsys(4). So this approach to hardware monitoring is no longer unique to OpenBSD. C.