Date: Fri, 19 Oct 2007 15:14:26 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org, "Constantine A. Murenin" <cnst@freebsd.org> Subject: Re: sensors fun.. Message-ID: <20071019151426.ttkynf788c0g8s4k@webmail.leidinger.net> In-Reply-To: <82533.1192797289@critter.freebsd.dk> References: <82533.1192797289@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Poul-Henning Kamp <phk@phk.freebsd.dk> (from Fri, 19 Oct 2007 12:34:49 +0000): > In message <20071019134842.rhlnbcqrbc4sc4o4@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071019151426.ttkynf788c0g8s4k>