Date: Fri, 9 Nov 2007 12:44:21 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: jhb@freebsd.org, phk@freebsd.org, imp@freebsd.org, rwatson@freebsd.org Cc: arch@freebsd.org, cnst@freebsd.org Subject: sensors framework continued (architecture) Message-ID: <20071109124421.3c1901b1@deskjail>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071109124421.3c1901b1>