sensors fun..

[Alexander Leidinger]

Quoting John Baldwin <jhb at freebsd.org> (from Wed, 17 Oct 2007 12:45:36 -0400):

Without commenting on specific parts of what you wrote, I think we  
need to clarify something before we proceed.

> Other things that might be nice:
>
> - IWBN to have a userland interface to sensors.  For example, if nothing else

Here's what I wrote to Julian (with minor modifications) this morning,  
before I've seen your mail here on arch.

I see several levels of stuff which can be named "sensors framework" here.

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.

Then there's something in the userland, what can also be named  
"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 collect data which is exported  
from the kernel, and to collect data from userland stuff. It would  
provide an interface to be able to query the in-machine data (some  
people may say SNMP can be used for this). Let's call this  
single-system sensors framework here.

And then there's something in the network what can be named "sensors  
framework". This part would be responsible to collect sensor data in  
the entire (sub-)network and provide an interface to query the data  
from the entire (sub-)network (an example can be nagios or some  
commercial offering). Let's call this group-level sensors framework  
for now.

The term "sensor data" may by ambiguous too. When I talk about sensor  
data, this can be some data from a device, like  
temperature/voltage/humidity/tv channel/ rotation speed/pressure  
level/fill level/coordinates/whatever (what we want to include of this  
stuff or not I don't talk about, e.g., ATM I don't see a need to  
provide the TV channel via the sensors framework). Sensor data can  
also be the status of a subsystem in the kernel, some database related  
things in userland, the hitrate per second of a webserver, or whatever.

All (more or less) of those things may in the end need to arrive in  
the group-level sensors framework. Before they arrive there, they  
ideally arrive in the single-system sensors framework (reduces probing  
complexity and the amount of work of the person who has to configure  
the group-level sensors framework). And parts of this stuff was  
collected from the kernel sensors framework by the single-system  
sensors framework.

The group-level sensors framework doesn't belong into FreeBSD IMO. For  
the single-system sensors framework I have no strong opinion (and with  
bsnmp we may have some sort of this already which just needs to be a  
little bit extend (MIBs), but this depends upon your needs and  
expectations).



What I would like to know is where you see problems with the above  
description and how your proposal fits into this description (if you  
don't see major flaws in the description).

To me it looks like your proposal spans more than one of the above  
described layers in one package. It seems you describe what I call  
single-system sensors framework above. It looks like you want to have  
this with parts of it in the kernel. I don't think this is a good idea  
as I don't think userland data should be feed into the kernel. Could  
you please describe where you see benefits of your architecture  
compared to the description I provided above?

Bye,
Alexander.

-- 
BOFH excuse #266:

All of the packets are empty

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137