sensors fun..

[Alexander Leidinger]

Quoting John-Mark Gurney <gurney_j at resnet.uoregon.edu> (from Fri, 19  
Oct 2007 10:56:02 -0700):

> Alexander Leidinger wrote this message on Thu, Oct 18, 2007 at 13:39 +0200:
>> 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.
>
> The project may have been about that, but what was committed included
> more than that (systat and sensord)...

systat shows what we have in hw.sensors. It allows users to use it  
already now. systat takes just a peek at it and displays it. It is not  
supposed to be a single-system monitoring solution, it just displays  
some kernel values like top and ps and the rest of systat does. John  
mentioned some kind of abstraction layer (a lib) to hide the  
implementation detail of the transport interface between the kernel  
and the userland. That's a good idea. I don't see where it is not  
possible to convert systat to such an abstraction layer (a lib) when  
it is available. In the mean time other people can add more sensors  
and are able test if it works with an easy tool.

For sensorsd: it's a tool to log some events to syslog, it's not a  
fully developed single-system monitoring tool. You want to have log  
traces somewhere when something goes wrong. And it doesn't make sense  
to me to keep the decission making process -- when is is ok to log  
something and when not based upon a config file -- in the kernel. This  
is something what can be done in userland and doesn't need kernel  
code. Like Poul mentioned, as much as possible shall be done in the  
userland. And sensorsd can also be converted to use a library to  
access the hw.sensors interface. Or maybe even removed, in case  
FreeBSD get's a single-system sensors framework which takes care about  
this.

> It does look like you are finally understanding what we have been
> talking about.. so I won't comment on the rest of it..

Sorry, but this is my point of view since a long time. That's nothing  
I developed just recently. I will answer to your mail where I talked  
about access to ISA stuff as time permits (maybe after I return from  
hospital in a week or two), and I try to do it in a verbose way so  
that the picture about Constantine's sensors framework is more clear  
(I hope).

And what you are talking about, doesn't seem to be what Poul is  
talking about. For example what Poul proposes in the thread here on  
arch (I've only read until the messages from Friday afternoon local  
time, but will catch up later) needs much more "business logic" in the  
kernel. If he wants to to an ioctl to tell the driver the polling  
interval, then this exceeds the pure transport layer idea and moves a  
lot of infrastructure which belongs IMO into a single-system sensors  
framework (timers for sensors which are not event driven, trigger  
values for sensors which measure analogue things, ...), but not in a  
kernel sensors framework. I can see benefits for something what he  
proposes in some cases (when events need to be reported very very  
fast), but all those cases I can come up with where this is needed to  
be in the kernel instead of in the userland, involves questions like  
the maximum time until an event has to be reported to an application,  
and if/how the FreeBSD kernel is able to fulfill such requirements. If  
something like this is only needed in very few cases, I don't think  
the kernel framework should be designed around that minority. The  
cases I can come up with are where the monitoring is not monitoring of  
the system (FreeBSD PC), but of something external. Something where  
the purpose of the system is to take care about some (e.g., life-)  
critical "application/service/device/...". I think those are special  
situations which may need special handling of such things. Something  
where a generic framework (and we all know that something what is  
supposed to be to work in a lot of cases often trades in simplicity to  
use and abstraction with speed and direct access) is in the way of the  
very special needs of the goal at hand in such a situation. For those  
reasons I asked several questions to Poul here in this thread (I don't  
assume I know every possible use-case), unfortunately he told me he is  
not interested in answering me those questions. What Poul proposes  
contradicts the pure transport layer idea you are talking about (and I  
think Constantines kernel sensors framework is an implementation of  
such a transport layer). As you are interested in a lean and mean  
kernel implementation, maybe you (or someone else) can answer me the  
questions I directed to Poul (in case you support him regarding this  
part too, and in case this was not answered in arch@ already since  
Friday afternoon (I will catch up with the discussion on arch@ later))  
to let me understand why a lot of code which would reside in userland  
(with e.g., Constantine's sensors framework or some other  
implementation) would need to move into the kernel with the  
architecture Poul proposes.

Bye,
Alexander.

P.S.: When I don't answer immediately to answers or questions, it's  
not because I don't want to answer. I will answer when I'm back from  
hospital.
-- 
Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics,
Benchmarks, and Delivery dates.

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