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 =20 12:34:49 +0000): > In message <20071019134842.rhlnbcqrbc4sc4o4@webmail.leidinger.net>, =20 > 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 =20 mentioned kernel sensors framework. How can the above description be =20 more sensible, when such an architecture is part of this description? =20 And related: you stated you haven't looked at the architecture behind =20 Constantines work because you don't like the idea itself. Do you have =20 now looked at the architecture, or how are you able to compare what is =20 written here with what is in Constantines work? If you have looked at =20 Constantines work now, could you please tell us about architectural =20 flaws which makes it not usable as a kernel sensors framework as =20 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 (=3D the polling policy) into =20 the kernel (with e.g, an ioctl)? What about the question about the rate between the number of sensors =20 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 =20 of using a fd. For event driven sensors I can see how this works =20 without putting the polling policy (the interval to poll) into the =20 kernel. For sensors which are not event driven, I fail to see how this =20 can be done without putting the polling policy (=3D the polling =20 interval) into the kernel. Would you please explain how an application =20 can wait for events from sensors which are not event driven without =20 putting the polling interval into the kernel? Related to this question =20 is the part about the ratio above. I would also like to know how you want to limit the rate of =20 kernel->userland crossings for even driven notifications without =20 putting the polling policy into the kernel, when the users polling =20 policy doesn't need the possible higher rate of a sensors notification =20 interval (we don't want to make the system unusable when several =20 sensors send to much events, don't we?). Bye, Alexander. --=20 Let thy maid servant be faithful, strong, and homely. =09=09-- Benjamin Franklin http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071019151426.ttkynf788c0g8s4k>