From owner-cvs-all@FreeBSD.ORG Wed Oct 17 20:36:14 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 E00D416A420; Wed, 17 Oct 2007 20:36:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 99B3413C494; Wed, 17 Oct 2007 20:36:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 00C581710B; Wed, 17 Oct 2007 20:36:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l9HKaBqe052236; Wed, 17 Oct 2007 20:36:11 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 17 Oct 2007 16:04:40 +0200." <20071017160440.b6fd00xs6cog888g@webmail.leidinger.net> Date: Wed, 17 Oct 2007 20:36:11 +0000 Message-ID: <52235.1192653371@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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: Wed, 17 Oct 2007 20:36:15 -0000 In message <20071017160440.b6fd00xs6cog888g@webmail.leidinger.net>, Alexander L eidinger writes: >Quoting Poul-Henning Kamp (from Tue, 16 Oct 2007 =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. 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. 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.