From owner-freebsd-arch@FreeBSD.ORG Fri Oct 19 13:16:12 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A6EB16A420; Fri, 19 Oct 2007 13:16:12 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id B6D5B13C459; Fri, 19 Oct 2007 13:16:10 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A564CA.dip.t-dialin.net [84.165.100.202]) by redbull.bpaserver.net (Postfix) with ESMTP id 862512E2F1; Fri, 19 Oct 2007 15:15:32 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8E3E95B480D; Fri, 19 Oct 2007 15:14:26 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9JDEQ9t075371; Fri, 19 Oct 2007 15:14:26 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 19 Oct 2007 15:14:26 +0200 Message-ID: <20071019151426.ttkynf788c0g8s4k@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 19 Oct 2007 15:14:26 +0200 From: Alexander Leidinger To: Poul-Henning Kamp References: <82533.1192797289@critter.freebsd.dk> In-Reply-To: <82533.1192797289@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.4, required 8, BAYES_00 -15.00, IMPRONONCABLE_2 1.50, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org, "Constantine A. Murenin" Subject: Re: sensors fun.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 13:16:12 -0000 Quoting Poul-Henning Kamp (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