From owner-freebsd-arch@FreeBSD.ORG Thu Jul 12 06:04:33 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18FDC16A469; Thu, 12 Jul 2007 06:04:33 +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 AC02D13C46A; Thu, 12 Jul 2007 06:04:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5559D.dip.t-dialin.net [84.165.85.157]) by redbull.bpaserver.net (Postfix) with ESMTP id 1DCDC2E22D; Thu, 12 Jul 2007 08:04:25 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 64AE45B5A49; Thu, 12 Jul 2007 08:02:13 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l6C62Bgu066090; Thu, 12 Jul 2007 08:02:11 +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, 12 Jul 2007 08:02:10 +0200 Message-ID: <20070712080210.j1gquzf3koogssso@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 12 Jul 2007 08:02:10 +0200 From: Alexander Leidinger To: John-Mark Gurney References: <20070711190546.4b202080@deskjail> <57627.1184175231@critter.freebsd.dk> <20070711195110.48820aff@deskjail> <20070711185718.GH1221@funkthat.com> In-Reply-To: <20070711185718.GH1221@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.827, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, J_CHICKENPOX_27 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, TW_PH 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Rui Paulo , Robert, Shteryana Shopova , "Constantine A. Murenin" , Poul-Henning Kamp , Watson , freebsd-arch@FreeBSD.org Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD 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, 12 Jul 2007 06:04:33 -0000 Quoting John-Mark Gurney (from Wed, 11 =20 Jul 2007 11:57:19 -0700): > Alexander Leidinger wrote this message on Wed, Jul 11, 2007 at 19:51 +0200= : >> Quoting "Poul-Henning Kamp" (Wed, 11 Jul 2007 =20 >> 17:33:51 +0000): >> > There is no benefit from having it in the kernel. >> >> You need to get some information out of the kernel somehow (you cut >> this part of my mail). And as far as I understand the high level >> description (presentation in the net) of this framework, this does this >> in an unified way. Do you propose to get the information out of the >> kernel in a non-uniform way? > > No you don't. The kernel is just another "transport" layer so to say.. > > We are proposing a unified way via a userland front end... The userland Nothing prevents you to do that. I just say that Constantine focuses =20 on getting data out of the kernel (as far as I understand his =20 project). The userland front end you propose needs also some kernel =20 data. How do you want to get this kernel data to userland? I'm =20 repeating me here. I already asked this to phk and he cut this part =20 away in his answers. Do you want to extend each _existing_ kernel driver which is able to =20 provide some interesting data (RAID status, HD status, ACPI battery =20 status, ... you can even export some or all process info with it) on =20 your own via hand-rolled code each time? I don't want that. I would =20 like to prefer an unified way which is able to get 80-95% of the =20 interesting data out of the kernel in a sane way (it's like asking if =20 we should integrate each NIC driver into the network stack, or if we =20 should design an unified interface which each NIC has to comply to; I =20 think it is also similar to the mixer interface on soundcards, most of =20 the cards use the unified mixer interface to provide you the =20 possibility to change the volume of several channels). For the =20 remaining 5-20% which don't fit into an unified interface in a sane =20 way we can extend existing drivers by hand. The userland front end you =20 propose then can be configured with a simple config file for the =20 unified way and with some plugins or whatever for the remaining 5-20% =20 stuff. For me Constantin's project is about providing a transport interface =20 of in-kernel sensor data from the kernel to userland. This can be used =20 in a lot of ways. Maybe hand it over to another transport layer to =20 export it to another system (SNMP comes to mind), or just look at it =20 via sysctl, or use a simple top-like display, or feed it to =20 MRTG/nagios/whatever in some way, or write a super mega sensor front =20 end which not only takes the kernel data but also some more data (you =20 could see nagios as such a front end, if you want). As another step you could extend Constantin's framework with a =20 connection to the kevent subsystem, so that interesting stuff provides =20 notification events. For example for continuous sensors (voltage, =20 temperature) you could register an event handler for a temperature =20 threshold which triggers at crossing. > library knows and can adapt to different ways of extracting the data.. > If you hard code the kernel interface, when someone comes along and > wants to write a complicated sensor in userland, he will then need to > hack a "kernel frontend" to take his userland generated data, shove it > into the kernel, just for another userland app to pull the data out.. No. The kernel is not supposed to handle all sensor data. The kernel =20 is only supposed to provide existing in-kernel sensor data to =20 userland. Maybe it also needs to provide some (more) meta data about =20 the sensor data to userland. So before you all repeat here saying that this project should be done =20 differently, please tell us how you want to get interesting sensor =20 data from existing kernel stuff out of the kernel without the need of =20 a high privilege userland process. In case you want to augment =20 existing drivers with some way to export this data, please also =20 describe how you approach is different from what Constantine is doing =20 ATM. Bye, Alexander. --=20 A day without sunshine is like night. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137