sensors fun..
Alexander Leidinger
Alexander at Leidinger.net
Fri Oct 19 06:16:12 PDT 2007
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
More information about the freebsd-arch
mailing list