From owner-cvs-src@FreeBSD.ORG Mon Oct 15 06:16:21 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C097816A417; Mon, 15 Oct 2007 06:16:21 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1468A13C458; Mon, 15 Oct 2007 06:16:20 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from outgoing.leidinger.net (p54A57699.dip.t-dialin.net [84.165.118.153]) by redbull.bpaserver.net (Postfix) with ESMTP id 23DA32E1BC; Mon, 15 Oct 2007 08:16:13 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id D390B5B480D; Mon, 15 Oct 2007 08:15:07 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9F6F7rL022172; Mon, 15 Oct 2007 08:15:07 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 15 Oct 2007 08:15:07 +0200 Message-ID: <20071015081507.yi9t4ot8asg0wcw4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 15 Oct 2007 08:15:07 +0200 From: Alexander Leidinger To: Poul-Henning Kamp References: <24712.1192384461@critter.freebsd.dk> In-Reply-To: <24712.1192384461@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.8, required 8, BAYES_00 -15.00, RDNS_DYNAMIC 0.10, SARE_FROM_SPAM_WORD3 0.10) X-BPAnet-MailScanner-From: netchild@freebsd.org X-Spam-Status: No Cc: Wilko Bulte , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org 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-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 06:16:21 -0000 Quoting Poul-Henning Kamp (from Sun, 14 Oct 2007 =20 17:54:21 +0000): > My only beef is with the architecture of the sensors framework, and > as a consequence thereof, with the actual code as well. When I asked you about a proposal how a better architecture looks =20 like, you didn't came up with an explanation and you didn't came up =20 with a list of things which you think are bad in the sensors =20 framework. You also didn't respond to counterarguments from me. I don't think it is fair to make such a noise, without coming up with =20 technical facts. Note: I don't object to backing out the commit. But as this seems to =20 be on the desk of core@, I wait for their decision regarding this (as =20 it is self contained and doesn't interfere with other stuff, we don't =20 need to hurry). > In OpenBSD the sensors framework has already turned into a dumping > ground, and I have all reason to belive that we will see the same > under FreeBSD. It will be what we make out of this. > See for instance Marc Balmers presentation from EuroBSDcon2007 about > putting radio-timecode receivers under the sensors framework, or I don't see a need to port this part instead of using the existing =20 time-infrastructure in our kernel (and I don't have my fingers in the =20 time related code at all like you, so I hope other people think =20 similar). > 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 =20 his own way of displaying the RAID status. It's like saying that each =20 network driver has to implement/display the stuff you can see with =20 ifconfig in its own way, instead of using the proper network driver =20 interface for this. > IFF we want to have a general catch-all framework for representing > any oddball state, LED or measurement in the computer, then we want > it to be much better structured than the code we are discussing now. Again, please point out specific deficits, so that Constantine and =20 others can explain why it is like it is and may be able to come up =20 with improvements which address your concerns. > But it is not even clear to me that we want such a framework, it makes > much more sense to keep the various indicators, measurements and > other input in their respective subsystems. We're back to the old discussion... please have a look there. You =20 failed to respond with a technical counterargument when I presented =20 the reasons why a framework to export sensoric data out of the kernel =20 is good to have (in short: similar reason why we have a standard way =20 of exporting status data from the network interface to ifconfig). > And IFF we add such an amount of code to FreeBSD, we want to have it > properly integrate into our kernel, using our device discovery > and registration (newbus) and not probing random (i2c) busses willy > nilly. Could you please explain how you want to integrate devices with =20 newbus, which are only accessible via the i2c bus? Feel free to show =20 us example code for one of those of our drivers which access the i2c =20 bus, which already existed before this commit. Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 GREAT MOMENTS IN AMERICAN HISTORY (#17): On November 13, Felix Unger was asked to remove himself from his place of residence.