sensors fun..

[Alexander Leidinger]

Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (from Fri, 19 Oct 2007  
09:41:04 +0000):

> In message <20071019113444.xinyc37x9cg0ckk0 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?

> The kernel-userland interface should happen over a filedescriptor
> (either device or unix-domain socket) so that whatever daemon we
> park on the fd can just use select/poll/kqueue to wait for events.

Please explain a little bit more of this architecture regarding the  
following questions:

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?

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?

Bye,
Alexander.

-- 
Two heads are better than one.
		-- John Heywood

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