Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

[Alexander Leidinger]

Quoting John-Mark Gurney <gurney_j at resnet.uoregon.edu> (from Wed, 11  
Jul 2007 11:57:19 -0700):

> Alexander Leidinger wrote this message on Wed, Jul 11, 2007 at 19:51 +0200:
>> Quoting "Poul-Henning Kamp" <phk at phk.freebsd.dk> (Wed, 11 Jul 2007   
>> 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  
on getting data out of the kernel (as far as I understand his  
project). The userland front end you propose needs also some kernel  
data. How do you want to get this kernel data to userland? I'm  
repeating me here. I already asked this to phk and he cut this part  
away in his answers.

Do you want to extend each _existing_ kernel driver which is able to  
provide some interesting data (RAID status, HD status, ACPI battery  
status, ... you can even export some or all process info with it) on  
your own via hand-rolled code each time? I don't want that. I would  
like to prefer an unified way which is able to get 80-95% of the  
interesting data out of the kernel in a sane way (it's like asking if  
we should integrate each NIC driver into the network stack, or if we  
should design an unified interface which each NIC has to comply to; I  
think it is also similar to the mixer interface on soundcards, most of  
the cards use the unified mixer interface to provide you the  
possibility to change the volume of several channels). For the  
remaining 5-20% which don't fit into an unified interface in a sane  
way we can extend existing drivers by hand. The userland front end you  
propose then can be configured with a simple config file for the  
unified way and with some plugins or whatever for the remaining 5-20%  
stuff.

For me Constantin's project is about providing a transport interface  
of in-kernel sensor data from the kernel to userland. This can be used  
in a lot of ways. Maybe hand it over to another transport layer to  
export it to another system (SNMP comes to mind), or just look at it  
via sysctl, or use a simple top-like display, or feed it to  
MRTG/nagios/whatever in some way, or write a super mega sensor front  
end which not only takes the kernel data but also some more data (you  
could see nagios as such a front end, if you want).

As another step you could extend Constantin's framework with a  
connection to the kevent subsystem, so that interesting stuff provides  
notification events. For example for continuous sensors (voltage,  
temperature) you could register an event handler for a temperature  
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  
is only supposed to provide existing in-kernel sensor data to  
userland. Maybe it also needs to provide some (more) meta data about  
the sensor data to userland.

So before you all repeat here saying that this project should be done  
differently, please tell us how you want to get interesting sensor  
data from existing kernel stuff out of the kernel without the need of  
a high privilege userland process. In case you want to augment  
existing drivers with some way to export this data, please also  
describe how you approach is different from what Constantine is doing  
ATM.

Bye,
Alexander.

-- 
A day without sunshine is like night.

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