From owner-cvs-all@FreeBSD.ORG Thu Oct 18 07:12:49 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 7BB1316A46C; Thu, 18 Oct 2007 07:12:49 +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 B520A13C468; Thu, 18 Oct 2007 07:12:48 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from outgoing.leidinger.net (p54A548C8.dip.t-dialin.net [84.165.72.200]) by redbull.bpaserver.net (Postfix) with ESMTP id 123072E06A; Thu, 18 Oct 2007 09:12:40 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 476A25B480D; Thu, 18 Oct 2007 09:11:34 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9I7BYT0072584; Thu, 18 Oct 2007 09:11:34 +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; Thu, 18 Oct 2007 09:11:34 +0200 Message-ID: <20071018091134.jzo7m88374ow00c8@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 18 Oct 2007 09:11:34 +0200 From: Alexander Leidinger To: Poul-Henning Kamp References: <52235.1192653371@critter.freebsd.dk> In-Reply-To: <52235.1192653371@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=-11.304, required 8, BAYES_00 -15.00, IMPRONONCABLE_2 1.50, J_CHICKENPOX_27 0.60, MIME_QP_LONG_LINE 1.40, 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-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: Thu, 18 Oct 2007 07:12:49 -0000 Quoting Poul-Henning Kamp (from Wed, 17 Oct 2007 =20 20:36:11 +0000): > In message <20071017160440.b6fd00xs6cog888g@webmail.leidinger.net>, =20 > Alexander L > eidinger writes: >> Quoting Poul-Henning Kamp (from Tue, 16 Oct 2007 =3D= 20 >> 17:32:40 +0000): > > This discussion is growing too many branches, I have pruned to the > central core for now: > >>> By defining the sensor API (on top of sysctl) at the kernel/userland >>> boundary you have decided that all sensor implementations must live >>> in the kernel, there is no room in your architecture for sensors >>> that live in userland. >> >> No, I didn't. I said (even last time when you first told us that you >> don't like the sensors framework), that the sensors framework is >> supposed to export data which lifes in the kernel to the userland. I >> never said the sensors framework is supposed to be the one and only >> way of getting status data from a running system. > > This is what I think is the most fatal flaw in this design. > > It is only an API for _some_ of the sensors in a system, and because > of that limitation, it invites people to try to shoehorn things > that do not belong there, into that subset. Again, we don't need to put everything what OpenBSD puts into =20 hw.sensors into our hw.sensors. If you object to include the time =20 stuff into hw.sensors when we have an existing and good API for this, =20 I don't object. I even agree with you, as this would be a good =20 technical argument. But this is unrelated to the sensors framework =20 (the API). It is related how this API is used. Nothing prevents us to =20 come up with a policy how this API shall be used. And for the "in a system" part, see my answer to Julian Elischer. You =20 are talking about something what I call "single-system sensor =20 framework" in the mail to him. > In this case, that puts code into the kernel that should under no > circumstances (have to) live there. > > The timekeeping sensors is a prefect example of that, since March > 2000 RFC2783 has defined the API for such stuff, but rather than > go and do things properly, somebody goes and implements DCF77 > decoding in the kernel. There was no modification to your time-stuff in FreeBSD. Instead of =20 complaining against the entire sensors framework, you could asks to =20 include a text somewhere, which tells that we are not interested to =20 add a sensor for the time stuff and why. > Kernel Architecture is just as much about preventing things as > enabling them. > > Sensors, as here presented, fails both criteria: It doesn't do > enough for the relevant subject matter, and doesn't keep > irrelevant stuff abay. Keeping the irrelevant stuff away means instantiating a policy. =20 Nothing prevents us from this. Feel free to start by contributing a =20 text which states that we don't want time sensors and why. For the =20 relevant things where you think it doesn't do enough, you should tell =20 us what you are talking about and why it is relevant. Maybe what you =20 want can be done without problems. As you haven't looked at the =20 framework itself (as you said you don't like the idea to an extend =20 that it is not even worth looking at it), you are in a weak position =20 to tell something can not be done with it (we've seen several times =20 that high level things you used to object against the sensors =20 framework integrate without problems into the sensors framework). 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 The man who can smile when things go wrong has thought of someone he can blame it on.