Date: Fri, 19 Oct 2007 12:34:49 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: arch@freebsd.org, "Constantine A. Murenin" <cnst@freebsd.org> Subject: Re: sensors fun.. Message-ID: <82533.1192797289@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 19 Oct 2007 13:48:42 %2B0200." <20071019134842.rhlnbcqrbc4sc4o4@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >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 ?) >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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82533.1192797289>