From owner-freebsd-arch@FreeBSD.ORG Mon Oct 22 11:32:59 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 CC28016A421; Mon, 22 Oct 2007 11:32:59 +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 3BD3613C4AA; Mon, 22 Oct 2007 11:32:58 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55D69.dip.t-dialin.net [84.165.93.105]) by redbull.bpaserver.net (Postfix) with ESMTP id 2C24A2E0EE; Mon, 22 Oct 2007 13:32:35 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 53B8C5B480D; Mon, 22 Oct 2007 13:31:28 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9MBVSW6083151; Mon, 22 Oct 2007 13:31:28 +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; Mon, 22 Oct 2007 13:31:27 +0200 Message-ID: <20071022133127.m6cdvrs3c4o4480c@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 22 Oct 2007 13:31:27 +0200 From: Alexander Leidinger To: John-Mark Gurney References: <200710171245.36949.jhb@freebsd.org> <20071018133949.1430dlowvks8w4kg@webmail.leidinger.net> <20071019175602.GD39759@funkthat.com> In-Reply-To: <20071019175602.GD39759@funkthat.com> 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=-12.904, required 8, BAYES_00 -15.00, J_CHICKENPOX_27 0.60, 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: Mon, 22 Oct 2007 11:32:59 -0000 Quoting John-Mark Gurney (from Fri, 19 =20 Oct 2007 10:56:02 -0700): > Alexander Leidinger wrote this message on Thu, Oct 18, 2007 at 13:39 +0200= : >> One level is in the kernel. It's just an export interface to transfer >> status data from the kernel to userland. The goal of this framework is >> IMO to "collect" all this data in the kernel and provide a single >> point of contact for the userland to query this in-kernel data. That's >> what the soc project was about. Let's call this kernel sensors >> framework here. > > The project may have been about that, but what was committed included > more than that (systat and sensord)... systat shows what we have in hw.sensors. It allows users to use it =20 already now. systat takes just a peek at it and displays it. It is not =20 supposed to be a single-system monitoring solution, it just displays =20 some kernel values like top and ps and the rest of systat does. John =20 mentioned some kind of abstraction layer (a lib) to hide the =20 implementation detail of the transport interface between the kernel =20 and the userland. That's a good idea. I don't see where it is not =20 possible to convert systat to such an abstraction layer (a lib) when =20 it is available. In the mean time other people can add more sensors =20 and are able test if it works with an easy tool. For sensorsd: it's a tool to log some events to syslog, it's not a =20 fully developed single-system monitoring tool. You want to have log =20 traces somewhere when something goes wrong. And it doesn't make sense =20 to me to keep the decission making process -- when is is ok to log =20 something and when not based upon a config file -- in the kernel. This =20 is something what can be done in userland and doesn't need kernel =20 code. Like Poul mentioned, as much as possible shall be done in the =20 userland. And sensorsd can also be converted to use a library to =20 access the hw.sensors interface. Or maybe even removed, in case =20 FreeBSD get's a single-system sensors framework which takes care about =20 this. > It does look like you are finally understanding what we have been > talking about.. so I won't comment on the rest of it.. Sorry, but this is my point of view since a long time. That's nothing =20 I developed just recently. I will answer to your mail where I talked =20 about access to ISA stuff as time permits (maybe after I return from =20 hospital in a week or two), and I try to do it in a verbose way so =20 that the picture about Constantine's sensors framework is more clear =20 (I hope). And what you are talking about, doesn't seem to be what Poul is =20 talking about. For example what Poul proposes in the thread here on =20 arch (I've only read until the messages from Friday afternoon local =20 time, but will catch up later) needs much more "business logic" in the =20 kernel. If he wants to to an ioctl to tell the driver the polling =20 interval, then this exceeds the pure transport layer idea and moves a =20 lot of infrastructure which belongs IMO into a single-system sensors =20 framework (timers for sensors which are not event driven, trigger =20 values for sensors which measure analogue things, ...), but not in a =20 kernel sensors framework. I can see benefits for something what he =20 proposes in some cases (when events need to be reported very very =20 fast), but all those cases I can come up with where this is needed to =20 be in the kernel instead of in the userland, involves questions like =20 the maximum time until an event has to be reported to an application, =20 and if/how the FreeBSD kernel is able to fulfill such requirements. If =20 something like this is only needed in very few cases, I don't think =20 the kernel framework should be designed around that minority. The =20 cases I can come up with are where the monitoring is not monitoring of =20 the system (FreeBSD PC), but of something external. Something where =20 the purpose of the system is to take care about some (e.g., life-) =20 critical "application/service/device/...". I think those are special =20 situations which may need special handling of such things. Something =20 where a generic framework (and we all know that something what is =20 supposed to be to work in a lot of cases often trades in simplicity to =20 use and abstraction with speed and direct access) is in the way of the =20 very special needs of the goal at hand in such a situation. For those =20 reasons I asked several questions to Poul here in this thread (I don't =20 assume I know every possible use-case), unfortunately he told me he is =20 not interested in answering me those questions. What Poul proposes =20 contradicts the pure transport layer idea you are talking about (and I =20 think Constantines kernel sensors framework is an implementation of =20 such a transport layer). As you are interested in a lean and mean =20 kernel implementation, maybe you (or someone else) can answer me the =20 questions I directed to Poul (in case you support him regarding this =20 part too, and in case this was not answered in arch@ already since =20 Friday afternoon (I will catch up with the discussion on arch@ later)) =20 to let me understand why a lot of code which would reside in userland =20 (with e.g., Constantine's sensors framework or some other =20 implementation) would need to move into the kernel with the =20 architecture Poul proposes. Bye, Alexander. P.S.: When I don't answer immediately to answers or questions, it's =20 not because I don't want to answer. I will answer when I'm back from =20 hospital. --=20 Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics, Benchmarks, and Delivery dates. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137