Re: sensors fun..

Quoting Poul-Henning Kamp <phk@xxxxxxxxxxxxxx> (from Fri, 19 Oct 2007 12:34:49 +0000):

In message <20071019134842.rhlnbcqrbc4sc4o4@xxxxxxxxxxxxxxxxxxxxx>, 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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: sensors fun..
    ... I see several levels of stuff which can be named "sensors framework" here. ... It's just an export interface to transfer status data from the kernel to userland. ...
    (freebsd-arch)
  • Re: sensors fun..
    ... >> single-system sensors framework above. ... >> as I don't think userland data should be feed into the kernel. ... Instead, I think the "public" interface that systat, ...
    (freebsd-arch)
  • Re: cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensor
    ... rights than using the userland parts of the sensors framework. ... but I have learned that the kernel should never be a dumping ...
    (freebsd-arch)
  • Re: sensors framework continued (architecture)
    ... This sounds like you propose more than one kernel access point for all ... the end you do a blocking wait, with slow sensors comming back later ... Why couldn't you tell multiple sensors to poll in one syscall? ... sensord about their placement in the hierarchy. ...
    (freebsd-arch)
  • sensors fun..
    ... etc. sensors report status via an object like this ... - I'm not entirely opposed to having kernel drivers for various known sensor ... Forcing all sensors to be in the kernel. ... consequences in the kernel than in userland. ...
    (freebsd-arch)