From owner-freebsd-arch@FreeBSD.ORG Sat Oct 20 02:57:11 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 D45B816A419 for ; Sat, 20 Oct 2007 02:57:11 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from mojo.ru (mojo.ru [84.252.152.63]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6AA13C44B for ; Sat, 20 Oct 2007 02:57:10 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from [192.168.0.16] (nc-76-6-108-199.dhcp.embarqhsd.net [76.6.108.199]) (authenticated bits=0) by mojo.ru (8.12.11.20060308/8.12.10) with ESMTP id l9K2eTig026284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Oct 2007 06:40:31 +0400 Message-ID: <47196A88.90104@FreeBSD.org> Date: Fri, 19 Oct 2007 22:40:08 -0400 From: "Constantine A. Murenin" Organization: Google Summer of Code 2007 Student @ The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-gb, en-gb-oed, en, en-us, ru, ru-ru, ru-su MIME-Version: 1.0 To: Poul-Henning Kamp References: <83490.1192810356@critter.freebsd.dk> In-Reply-To: <83490.1192810356@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Alexander@Leidinger.net, "Constantine A. Murenin" , arch@FreeBSD.org 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: Sat, 20 Oct 2007 02:57:11 -0000 On 19/10/2007 12:12, Poul-Henning Kamp wrote: > In message <20071019.100516.74722974.imp@bsdimp.com>, Warner Losh writes: > > >>>The kernel-userland interface should happen over a filedescriptor >>>(either device or unix-domain socket) so that whatever daemon we >>>park on the fd can just use select/poll/kqueue to wait for events. >> >>If we're going to have a stream of data from the kernel, is there any >>reason to invent another daemon for that? We already have devd that >>deals with a number of disparate events from the kernel in a fairly >>generic way. > > > The kernel and userland sensors would result in two kinds of data, > measurements ("32°C") and events ("new sensor", "high temp") In such case, measurements can be taken through the sensors framework and events could be sent via the devctl(4) mechanism. So it doesn't look like we disagree so far, now does it? :-) > devd should not see the measurements, but it might be a good idea > if it could see the events from all sensors (userland AND kernel). Sure, we can add some devctl_notify calls to the functions that are used to register sensor devices. I don't see any problem with this. As far as the userland part goes -- well, I totally agree with Alexander about his email mentioning eierlegendewollmichsau. :-) Cheers, Constantine.