From owner-freebsd-arch@FreeBSD.ORG Fri Nov 9 11:47:41 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 A2B2D16A418; Fri, 9 Nov 2007 11:47:41 +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 DA54413C4B7; Fri, 9 Nov 2007 11:47:40 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5407C.dip.t-dialin.net [84.165.64.124]) by redbull.bpaserver.net (Postfix) with ESMTP id 781BA2E35D; Fri, 9 Nov 2007 12:44:24 +0100 (CET) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id EC2B03148AE3; Fri, 9 Nov 2007 12:44:21 +0100 (CET) Date: Fri, 9 Nov 2007 12:44:21 +0100 From: Alexander Leidinger To: jhb@freebsd.org, phk@freebsd.org, imp@freebsd.org, rwatson@freebsd.org Message-ID: <20071109124421.3c1901b1@deskjail> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=1.269, required 8, BAYES_40 -0.18, J_CHICKENPOX_43 0.60, J_CHICKENPOX_66 0.60, RDNS_DYNAMIC 0.10, TW_PH 0.08, TW_VC 0.08) X-BPAnet-MailScanner-SpamScore: s X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org, cnst@freebsd.org Subject: 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, 09 Nov 2007 11:47:41 -0000 Hi, I'm back from the surgery and am in a state where I don't have to take any = medication since some days. So I think I'm fit enough to move forward here.= As there was no further discussion since nearly two weeks on this, I summa= rize what we have so far. First some definitions so that we have a common u= nderstanding of the parts involved. Then what seems to be the current state= of affairs from an architectural point of view. The definitions: Kernel sensors framework: It's just an export interface to transfer status = data from the kernel to userland. The goal of this framework is to "collect= " all this data in the kernel and provide a single point of contact for the= userland to query this in-kernel data. In-kernel data means raw data from = devices here, e.g., temperature data of one particular sensor, but not a co= mputed value like "kern.ipc.maxsockets-kern.ipc.numopensockets". What data = is exported how (via the sensors interface, via sysctl kern.xxx or anything= else) is up to a decission for the data based upon rules we come up with (= explicitely or implicitely). An explicite rule could be to not export time = related data via the sensors framework but via our existing standards compl= iant API. An implicit rule could be to export temperature data from the ker= nel via the sensors framework. Single-system sensors framework: This part would be responsible to be a sin= gle point of contact to query the status data of the entire system. This us= erland part would be responsible to automatically collect data which is exp= orted from the kernel (raw data) via the sensors framework, and to collect = data from userland stuff (either application specific data like number of c= hilds of a webserver, or a computed value from raw data like "kern.ipc.maxs= ockets-kern.ipc.numopensockets"). It would provide an interface to be able = to query the in-machine data. It could also be used to augment data from th= e kernel sensors framework with additional meta data which can not be autom= atically determined (e.g. location, name-override, ...). Group-level sensors framework: This part would be responsible to collect se= nsor data in the entire (sub-)network from the single-system sensors framew= ork and provide an interface to query the data from the entire (sub-)networ= k (an example would be nagios, some commercial offering, or something compl= etely different). The current state of affairs: We want a kernel sensors framework and a single-system sensors framework in= FreeBSD. For the kernel sensors framework phk proposes (Message-ID: <81952.119278686= 4@critter.freebsd.dk>, <82533.1192797289@critter.freebsd.dk>) a fd which su= pports select/poll/kevent as the interface between the kernel and the userl= and (Julian and Max also proposed an fd based interface without going into = as much details regarding events like Poul did). An ioctl() could be used t= o specify the polling intervall of sensors which are not event-driven. This= implies that we have to move the polling intervall code for non-event driv= en sensors from the userland to the kernel. This is contrary to his requst = that as much as possible is done in userland. Having this in kernel is bene= ficial for time critical sensor data where a fast reaction to critical situ= ations is needed, but in such a situation we need to talk about garanteed r= eaction times and if FreeBSD is able to meet those requirements or if a rea= l-time OS is better suited for this application scenario. As we have no har= d data provided in this discussion regarding this topic I would say having = the polling intervall logic in the kernel is premature optimization so far. Warner proposes to use an existing interface (devd) for event driven sensor= s (<20071019.100516.74722974.imp@bsdimp.com>). Poul agrees that events (lik= e "high temp" and similar, but not the actual raw data like "32=C2=B0C") co= uld be send to devd instead. I like to extend this so that it is send over = the devd socket, but that devd should not react to every sensor related eve= nt, but the signle-system sensor framework is supposed to handle such event= s. Devd could react to those events too, if desired by the admin, but it do= esn't make sense to let devd handle all events by default. It may make sens= e to let devd handle events which require immediate action (shutting down (= sub)systems, sending emails (if desired), ...), but if the group-level sens= ors framework handles parts of this (like sending notifications), devd inte= raction for those is not desired (the handling of events in devd needs to b= e decided on a case by case basis). This would require to extend the devctl= interface to allow more than one reader. Robert thinks that sysctl MIBs offer "a more semantically rich and, to be h= onest, better defined way of interacting with live subsystems than device f= iles do in a generic sense". Nobody objected to this opinion or provided re= asons why a fd based approach is better than a sysctl MIB based approach. R= icardo Nabinger Sanchez points out http://www.ietf.org/rfc/rfc3433.txt (RFC= for sensor MIBs).=20 The single-system sensors framework should be implemented in a library whic= h userland programs like systat, SNMP or other monitoring daemons use (jhb,= Message-Id: <200710181450.38224.jhb@freebsd.org>). The kernel-userland int= erface of the kernel sensors framework would be an internal interface of Fr= eeBSD and every program which wants access to a sensor would have to use th= e library as the official interface. So to sum it up it looks like the architecture looks as follows: - using sysctls for centralized exporting of sensor data from kernel to userland (polling interface for userland polling code) - using devctl_notify() for change-events (the userland can then read the changed value via the sysctl interface) - writting a library (the single-system sensors framework backend) which abstracts away the kernel-userland interface of the kernel sensors framework and provides an official interface for userland programs to all sensors in the system Did I got the architecture/summary right or did I miss a mail on arch@ whic= h made the fd based approach more beneficial than the sysctl+devctl based a= pproach? Bye, Alexander. --=20 Fashion is a form of ugliness so intolerable that we have to alter it every six months. -- Oscar Wilde http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137