sensors framework continued (architecture)

[Alexander Leidinger]

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 summarize what we have so far. First some definitions so that we have a common understanding 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 computed 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 compliant API. An implicit rule could be to export temperature data from the kernel via the sensors framework.

Single-system sensors framework: This part would be responsible to be a single point of contact to query the status data of the entire system. This userland part would be responsible to automatically collect data which is exported from the kernel (raw data) via the sensors framework, and to collect data from userland stuff (either application specific data like number of childs of a webserver, or a computed value from raw data like "kern.ipc.maxsockets-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 the kernel sensors framework with additional meta data which can not be automatically determined (e.g. location, name-override, ...).

Group-level sensors framework: This part would be responsible to collect sensor data in the entire (sub-)network from the single-system sensors framework and provide an interface to query the data from the entire (sub-)network (an example would be nagios, some commercial offering, or something completely 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.1192786864 at critter.freebsd.dk>, <82533.1192797289 at critter.freebsd.dk>) a fd which supports select/poll/kevent as the interface between the kernel and the userland (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 to 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 driven 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 beneficial for time critical sensor data where a fast reaction to critical situations is needed, but in such a situation we need to talk about garanteed reaction times and if FreeBSD is able to meet those requirements or if a real-time OS is better suited for this application scenario. As we have no hard 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 sensors (<20071019.100516.74722974.imp at bsdimp.com>). Poul agrees that events (like "high temp" and similar, but not the actual raw data like "32°C") could 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 event, but the signle-system sensor framework is supposed to handle such events. Devd could react to those events too, if desired by the admin, but it doesn't make sense to let devd handle all events by default. It may make sense to let devd handle events which require immediate action (shutting down (sub)systems, sending emails (if desired), ...), but if the group-level sensors framework handles parts of this (like sending notifications), devd interaction for those is not desired (the handling of events in devd needs to be 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 honest, better defined way of interacting with live subsystems than device files do in a generic sense". Nobody objected to this opinion or provided reasons why a fd based approach is better than a sysctl MIB based approach. Ricardo Nabinger Sanchez points out http://www.ietf.org/rfc/rfc3433.txt (RFC for sensor MIBs). 

The single-system sensors framework should be implemented in a library which userland programs like systat, SNMP or other monitoring daemons use (jhb, Message-Id: <200710181450.38224.jhb at freebsd.org>). The kernel-userland interface of the kernel sensors framework would be an internal interface of FreeBSD and every program which wants access to a sensor would have to use the 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@ which made the fd based approach more beneficial than the sysctl+devctl based approach?

Bye,
Alexander.

-- 
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 = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137