From owner-freebsd-arch@FreeBSD.ORG Thu Oct 18 11:41:06 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 C6DBD16A41B; Thu, 18 Oct 2007 11:41:06 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 6F43113C46B; Thu, 18 Oct 2007 11:41:05 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A56405.dip.t-dialin.net [84.165.100.5]) by redbull.bpaserver.net (Postfix) with ESMTP id 40C1E2E12E; Thu, 18 Oct 2007 13:40:55 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 6FD345B480D; Thu, 18 Oct 2007 13:39:49 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9IBdnE3017134; Thu, 18 Oct 2007 13:39:49 +0200 (CEST) (envelope-from Alexander@Leidinger.net) 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 13:39:49 +0200 Message-ID: <20071018133949.1430dlowvks8w4kg@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 18 Oct 2007 13:39:49 +0200 From: Alexander Leidinger To: John Baldwin References: <200710171245.36949.jhb@freebsd.org> In-Reply-To: <200710171245.36949.jhb@freebsd.org> 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=-13.504, required 8, BAYES_00 -15.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org, "Constantine A. Murenin" Subject: Re: sensors fun.. 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: Thu, 18 Oct 2007 11:41:07 -0000 Quoting John Baldwin (from Wed, 17 Oct 2007 12:45:36 -0400= ): Without commenting on specific parts of what you wrote, I think we =20 need to clarify something before we proceed. > Other things that might be nice: > > - IWBN to have a userland interface to sensors. For example, if nothing e= lse Here's what I wrote to Julian (with minor modifications) this morning, =20 before I've seen your mail here on arch. I see several levels of stuff which can be named "sensors framework" here. One level is in the kernel. It's just an export interface to transfer =20 status data from the kernel to userland. The goal of this framework is =20 IMO to "collect" all this data in the kernel and provide a single =20 point of contact for the userland to query this in-kernel data. That's =20 what the soc project was about. Let's call this kernel sensors =20 framework here. Then there's something in the userland, what can also be named =20 "sensors framework". This part would be responsible to be a single =20 point of contact to query the status data of the entire system. This =20 userland part would be responsible to collect data which is exported =20 from the kernel, and to collect data from userland stuff. It would =20 provide an interface to be able to query the in-machine data (some =20 people may say SNMP can be used for this). Let's call this =20 single-system sensors framework here. And then there's something in the network what can be named "sensors =20 framework". This part would be responsible to collect sensor data in =20 the entire (sub-)network and provide an interface to query the data =20 from the entire (sub-)network (an example can be nagios or some =20 commercial offering). Let's call this group-level sensors framework =20 for now. The term "sensor data" may by ambiguous too. When I talk about sensor =20 data, this can be some data from a device, like =20 temperature/voltage/humidity/tv channel/ rotation speed/pressure =20 level/fill level/coordinates/whatever (what we want to include of this =20 stuff or not I don't talk about, e.g., ATM I don't see a need to =20 provide the TV channel via the sensors framework). Sensor data can =20 also be the status of a subsystem in the kernel, some database related =20 things in userland, the hitrate per second of a webserver, or whatever. All (more or less) of those things may in the end need to arrive in =20 the group-level sensors framework. Before they arrive there, they =20 ideally arrive in the single-system sensors framework (reduces probing =20 complexity and the amount of work of the person who has to configure =20 the group-level sensors framework). And parts of this stuff was =20 collected from the kernel sensors framework by the single-system =20 sensors framework. The group-level sensors framework doesn't belong into FreeBSD IMO. For =20 the single-system sensors framework I have no strong opinion (and with =20 bsnmp we may have some sort of this already which just needs to be a =20 little bit extend (MIBs), but this depends upon your needs and =20 expectations). What I would like to know is where you see problems with the above =20 description and how your proposal fits into this description (if you =20 don't see major flaws in the description). To me it looks like your proposal spans more than one of the above =20 described layers in one package. It seems you describe what I call =20 single-system sensors framework above. It looks like you want to have =20 this with parts of it in the kernel. I don't think this is a good idea =20 as I don't think userland data should be feed into the kernel. Could =20 you please describe where you see benefits of your architecture =20 compared to the description I provided above? Bye, Alexander. --=20 BOFH excuse #266: All of the packets are empty http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137