sensors fun..

[Poul-Henning Kamp]

In message <20071019134842.rhlnbcqrbc4sc4o4 at webmail.leidinger.net>, Alexander L
eidinger writes:

>>> I was thinking you talk about the interface between the kernel and the
>>> userland. Now I think that you talk more or less about something which
>>> could be implemented e.g., as an userland library which not only polls
>>> the kernel sensors framework, but provides the single-system sensor
>>> data (and could be a base of a singe-system sensor daemon which feeds
>>> its data to a group-level sensors framework). Does this sound like
>>> what you have in mind?
>>
>> It certainly sounds more sensible.
>
>More sensible than what?

Than the OpenBSD sensors concept

>What to do with sensors which aren't event based or don't have a  
>predefined polling interval (e.g., temperature and humidity)? What do  
>you think will the ratio be between the amount of sensors with and  
>without something like this?

They poll at whatever rate the application ask them to, (using an
ioctl ?)

>How is the kernel supposed to know what polling policy the user is  
>interested in (every 5sec/every minute/every 5 minutes/whatever)? Why  
>should this policy/procedure life in the kernel?

Nobody said the policy should live in the kernel.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.