From owner-freebsd-arch@FreeBSD.ORG Fri Nov 16 10:29:29 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85FE616A41A; Fri, 16 Nov 2007 10:29:29 +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 D99AB13C447; Fri, 16 Nov 2007 10:29:28 +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 9E95F17105; Fri, 16 Nov 2007 10:29:26 +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 lAGATPDE027727; Fri, 16 Nov 2007 10:29:26 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 13 Nov 2007 21:51:17 +0100." <20071113215117.3b9bab8c@deskjail> Date: Fri, 16 Nov 2007 10:29:25 +0000 Message-ID: <27726.1195208965@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: rwatson@freebsd.org, cnst@freebsd.org, imp@freebsd.org, arch@freebsd.org Subject: Re: sensors framework continued (architecture) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 10:29:29 -0000 In message <20071113215117.3b9bab8c@deskjail>, Alexander Leidinger writes: Alexander, This discussion is leading nowhere, because no matter what we tell you, your only focus is to prove that "sysctl can do that also". There are so many interesting things we could work together on in this area, and I have quite a bit of interesting code I could contribute (see http://phk.freebsd.dk/phkrel/Measure.20071017.tgz), but we never get to that point because of your rather childish insistence that sysctl is the only and right way to do this. It also gets more than a bit tedious after a while, and I have decided that I do not want to continue wasting my time discussing this, until you are willing to compromise on your sysctl addiction. So let me make my position 100% clear: 1. I would LOVE to see FreeBSD grow competent support for managing sensors, (and possibly actuators). 2. I have many years of experience and a fair bit of code I can and will contribute to such a project. 3. I don't want some half-assed, badly thought out "it works for me" crap, because I have spent most of my FreeBSD years cleaning that sort of stuff up, and I'm trying to break the habbit. 4. Therefore, any attempt to get sensorcode into FreeBSD that does not comply with the architectural model set out below will be met with my full effort of resistance. 5. The ball is now in your court. Sincerely, Poul-Henning High-level architectural view of sensor support ----------------------------------------------- N * application (linked -lsensor) | | 1 * sensord ---- N * userland-sensors (linked -lsensor) | | 1 * sensor multiplex device driver | | N * kernel sensors (There may also be a connection from the multiplex driver to devd(8) or it may be from sensord(8) or possibly both, but that could come later.) The sensor daemon is there to act as clearing-house and single configuration point for the sensors, because I really don't want to have all the sensors polled by all the applications and I don't want all the applications to have to read the config file and do calibration/alarm calculations themselves. In my experience, it makes sense to not restrict the userland side communication to UNIX sockets, since being able to access another machines sensors using TCP saves a userland process on that machine. -- 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.