Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Oct 2007 10:05:16 -0600 (MDT)
From:      Warner Losh <imp@bsdimp.com>
To:        phk@phk.freebsd.dk
Cc:        Alexander@Leidinger.net, cnst@freebsd.org, arch@freebsd.org
Subject:   Re: sensors fun.. 
Message-ID:  <20071019.100516.74722974.imp@bsdimp.com>
In-Reply-To: <81952.1192786864@critter.freebsd.dk>
References:  <20071019113444.xinyc37x9cg0ckk0@webmail.leidinger.net> <81952.1192786864@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Subject: Re: sensors fun.. 
Date: Fri, 19 Oct 2007 09:41:04 +0000

> In message <20071019113444.xinyc37x9cg0ckk0@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.
> 
> 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.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071019.100516.74722974.imp>