sensors fun..

[Alexander Leidinger]

Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (from Fri, 19 Oct 2007  
12:34:49 +0000):

> 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

Constantines sensors framework is an implementation of the above  
mentioned kernel sensors framework. How can the above description be  
more sensible, when such an architecture is part of this description?  
And related: you stated you haven't looked at the architecture behind  
Constantines work because you don't like the idea itself. Do you have  
now looked at the architecture, or how are you able to compare what is  
written here with what is in Constantines work? If you have looked at  
Constantines work now, could you please tell us about architectural  
flaws which makes it not usable as a kernel sensors framework as  
described above (the part which you called more sensible)?

>> 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 ?)

So you want to put the polling interval (= the polling policy) into  
the kernel (with e.g, an ioctl)?

What about the question about the rate between the number of sensors  
with and without event driven notifications?

>> 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.

You wrote that an application can wait for an event with your approach  
of using a fd. For event driven sensors I can see how this works  
without putting the polling policy (the interval to poll) into the  
kernel. For sensors which are not event driven, I fail to see how this  
can be done without putting the polling policy (= the polling  
interval) into the kernel. Would you please explain how an application  
can wait for events from sensors which are not event driven without  
putting the polling interval into the kernel? Related to this question  
is the part about the ratio above.

I would also like to know how you want to limit the rate of  
kernel->userland crossings for even driven notifications without  
putting the polling policy into the kernel, when the users polling  
policy doesn't need the possible higher rate of a sensors notification  
interval (we don't want to make the system unusable when several  
sensors send to much events, don't we?).

Bye,
Alexander.

-- 
Let thy maid servant be faithful, strong, and homely.
		-- Benjamin Franklin

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